<?xml version="1.0" encoding="UTF-8"?>
<rss xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" version="2.0">
  <channel>
    <title>topic ArcSDE security: ST_GEOMETRY EXTPROC listener exploits and hardening the SDE schema? in Data Management Questions</title>
    <link>https://community.esri.com/t5/data-management-questions/arcsde-security-st-geometry-extproc-listener/m-p/685143#M38860</link>
    <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;SPAN&gt;At ArcSDE 9.3.1 for Oracle I didn't like what I saw regarding out of the box security for ArcSDE:&lt;/SPAN&gt;&lt;BR /&gt;&lt;STRONG&gt;"Harden" ArcSDE repository on Oracle: do not grant privileges to PUBLIC role unnecessarily&lt;/STRONG&gt;&lt;BR /&gt;&lt;A href="http://ideas.arcgis.com/ideaView?id=087300000008HY6AAM"&gt;http://ideas.arcgis.com/ideaView?id=087300000008HY6AAM&lt;/A&gt;&lt;BR /&gt;&lt;BR /&gt;&lt;SPAN&gt;Unless I'm mistaken, the SDE schema / ArcSDE repository violates all three basic principles of security: &lt;/SPAN&gt;&lt;STRONG&gt;C&lt;/STRONG&gt;&lt;SPAN&gt;onfidentiality, &lt;/SPAN&gt;&lt;STRONG&gt;I&lt;/STRONG&gt;&lt;SPAN&gt;ntegrity, and &lt;/SPAN&gt;&lt;STRONG&gt;A&lt;/STRONG&gt;&lt;SPAN&gt;vailability as described in the Idea link above. There's a KB article out there somewhere saying how to manually harden the SDE repository and that's welcome. But it should probably be a bit more front and center in the install documentation--e.g. if this has not been done already, linked to the KB article from the install docs please. It may not occur to someone up front to harden the SDE repository. &lt;/SPAN&gt;&lt;BR /&gt;&lt;BR /&gt;&lt;SPAN&gt;The vast majority of security exploits are evidently caused by misconfiguration according to Cloud Security expert Steve Riley (during his spectacular &lt;/SPAN&gt;&lt;A href="http://www.esri.com/events/devsummit/videos/video3.html"&gt;2012 DevSummit Keynote--view it online&lt;/A&gt;&lt;SPAN&gt;). Presuming that's true, it might be nice to alert folks up front what countermeasures they might take. Rather than learn what ought to have been done up front post-breach... &lt;/SPAN&gt;&lt;BR /&gt;&lt;BR /&gt;&lt;STRONG&gt;ArcSDE Security Improvements at 10.1?&lt;/STRONG&gt;&lt;BR /&gt;&lt;SPAN&gt;I've not looked at privileges granted at ArcSDE 10 to see if there's been improvement. Hoping such is the case at ArcSDE 10.1 Final. While I understand hardening the SDE schema requires a bit more work up front (e.g. revoking grants from PUBLIC and granting to data owners, etc per the KB article), it's an investment worth considering.&lt;/SPAN&gt;&lt;BR /&gt;&lt;BR /&gt;&lt;STRONG&gt;Security Issues With EXTPROC Oracle Listener for ST_GEOMETRY Spatial SQL Functions? &lt;/STRONG&gt;&lt;BR /&gt;&lt;SPAN&gt;Someone added a comment to the Idea entry above questioning the use of EXTPROC, e.g. presumably the listener for ST_GEOMETRY spatial SQL functions. The only best practice I know of, one mentioned in Esri documentation and one we've implemented, is to create a second, less privileged user to run a second, dedicated Oracle listener for ST_GEOMETRY. Are there ways to harden this further? What are the issues if any? No system is 100% secure unless it's unplugged. But what other due diligence, relatively low effort / low cost items can ArcSDE admins perform to ensure ArcSDE is more secure than what one gets out of the box?&lt;/SPAN&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
    <pubDate>Sat, 14 Apr 2012 08:08:19 GMT</pubDate>
    <dc:creator>danan</dc:creator>
    <dc:date>2012-04-14T08:08:19Z</dc:date>
    <item>
      <title>ArcSDE security: ST_GEOMETRY EXTPROC listener exploits and hardening the SDE schema?</title>
      <link>https://community.esri.com/t5/data-management-questions/arcsde-security-st-geometry-extproc-listener/m-p/685143#M38860</link>
      <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;SPAN&gt;At ArcSDE 9.3.1 for Oracle I didn't like what I saw regarding out of the box security for ArcSDE:&lt;/SPAN&gt;&lt;BR /&gt;&lt;STRONG&gt;"Harden" ArcSDE repository on Oracle: do not grant privileges to PUBLIC role unnecessarily&lt;/STRONG&gt;&lt;BR /&gt;&lt;A href="http://ideas.arcgis.com/ideaView?id=087300000008HY6AAM"&gt;http://ideas.arcgis.com/ideaView?id=087300000008HY6AAM&lt;/A&gt;&lt;BR /&gt;&lt;BR /&gt;&lt;SPAN&gt;Unless I'm mistaken, the SDE schema / ArcSDE repository violates all three basic principles of security: &lt;/SPAN&gt;&lt;STRONG&gt;C&lt;/STRONG&gt;&lt;SPAN&gt;onfidentiality, &lt;/SPAN&gt;&lt;STRONG&gt;I&lt;/STRONG&gt;&lt;SPAN&gt;ntegrity, and &lt;/SPAN&gt;&lt;STRONG&gt;A&lt;/STRONG&gt;&lt;SPAN&gt;vailability as described in the Idea link above. There's a KB article out there somewhere saying how to manually harden the SDE repository and that's welcome. But it should probably be a bit more front and center in the install documentation--e.g. if this has not been done already, linked to the KB article from the install docs please. It may not occur to someone up front to harden the SDE repository. &lt;/SPAN&gt;&lt;BR /&gt;&lt;BR /&gt;&lt;SPAN&gt;The vast majority of security exploits are evidently caused by misconfiguration according to Cloud Security expert Steve Riley (during his spectacular &lt;/SPAN&gt;&lt;A href="http://www.esri.com/events/devsummit/videos/video3.html"&gt;2012 DevSummit Keynote--view it online&lt;/A&gt;&lt;SPAN&gt;). Presuming that's true, it might be nice to alert folks up front what countermeasures they might take. Rather than learn what ought to have been done up front post-breach... &lt;/SPAN&gt;&lt;BR /&gt;&lt;BR /&gt;&lt;STRONG&gt;ArcSDE Security Improvements at 10.1?&lt;/STRONG&gt;&lt;BR /&gt;&lt;SPAN&gt;I've not looked at privileges granted at ArcSDE 10 to see if there's been improvement. Hoping such is the case at ArcSDE 10.1 Final. While I understand hardening the SDE schema requires a bit more work up front (e.g. revoking grants from PUBLIC and granting to data owners, etc per the KB article), it's an investment worth considering.&lt;/SPAN&gt;&lt;BR /&gt;&lt;BR /&gt;&lt;STRONG&gt;Security Issues With EXTPROC Oracle Listener for ST_GEOMETRY Spatial SQL Functions? &lt;/STRONG&gt;&lt;BR /&gt;&lt;SPAN&gt;Someone added a comment to the Idea entry above questioning the use of EXTPROC, e.g. presumably the listener for ST_GEOMETRY spatial SQL functions. The only best practice I know of, one mentioned in Esri documentation and one we've implemented, is to create a second, less privileged user to run a second, dedicated Oracle listener for ST_GEOMETRY. Are there ways to harden this further? What are the issues if any? No system is 100% secure unless it's unplugged. But what other due diligence, relatively low effort / low cost items can ArcSDE admins perform to ensure ArcSDE is more secure than what one gets out of the box?&lt;/SPAN&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
      <pubDate>Sat, 14 Apr 2012 08:08:19 GMT</pubDate>
      <guid>https://community.esri.com/t5/data-management-questions/arcsde-security-st-geometry-extproc-listener/m-p/685143#M38860</guid>
      <dc:creator>danan</dc:creator>
      <dc:date>2012-04-14T08:08:19Z</dc:date>
    </item>
  </channel>
</rss>

