Security Inside Out: Where to Start?
By Troy Kitch on Nov 26, 2013
Guest article written by Eric Maurice, Director for Oracle Software Security Assurance.
In my current role, I assist with the definition and communication of many Oracle security policies as they apply to the development of our products as well as how we look at security internally for the protection of our corporate systems and the systems we host on behalf of our customers. Since Oracle runs its business on Oracle products, our security organizations have developed extensive expertise in how to secure our products “across the stack” and in various deployment scenarios. I often interact with customers to answer security questions related to our products (e.g., questions around Oracle’s secure development and vulnerability handling practices) and security processes (e.g., questions related to how we handle security patching and define and enforce secure configurations).
In addition, I am periodically engaged in more general discussions with customers in regards to how to best strategically approach security in their organizations. These conversations are usually prompted by failed security audits of some systems, change in IT management in the organization (new IT managers or CISO), launch of major IT projects, or suspicions and sometimes evidence of a past security incident. In such instances, a renewed focus on securing the organization can quickly become overwhelming. There are many IT frameworks intended to help organizations tackle security policies such as COBIT and ISO/IEC 27000. However, what IT professionals more often need in these instances is to adopt a security philosophy, and to switch to a new perspective on IT operations. Only then can they fully leverage the various frameworks available to them, as opposed to blindly engaging in a security documentation exercise that has little practical value for the organization besides generating healthy profits for outside auditors and pen testers.
So where do you start? What intellectual process must you follow to take a fresh look at your organization’s security posture? In my opinion, the first challenge is to come to the realization that your organization needs to “get back to the basics.” What are your top 10 business-critical systems (or mission-critical systems)? What components of your IT infrastructure comprise these business-critical systems? What does it mean if any one of them is compromised or unavailable? What are the top threats in your environment? In my experience, many organizations’ IT investments or security policies are not intended to address the top threats that affect their business critical systems. Are yours? Do you actually invest your time and security resources to address significant threats to your business-critical systems? The ugly truth that we all have to come to term with is that unless you have an unlimited IT budget or a very small IT environment to manage (and no operational needs to ever change it), you cannot afford to strongly secure all your systems equally well all the time.
The second challenge with taking a fresh look at your organization’s security posture is thinking multidimensionally. Security does not exist in a silo, even though most large organizations where specialization is required have such IT silos. Are DBA’s aware of existing network security access controls around the databases they manage? Do they understand the security model of the applications? Do application managers and users understand database security models? Have system security configurations been developed collaboratively between the different IT staffs? Do systems administrators understand the chain of trust that exists between the different systems they manage? This is where the traditional concept of “security-in-depth” comes to play. Has the organization implemented complementary (and not necessarily redundant) security controls across the technology stack in the enterprise? For example, application bypass attacks can be prevented by strong database access control security policies. OS access control policies should be enforced so that privileges around system files as well as against relevant database and application files (and log files), and resources on all servers in the environment are tightly controlled. At a network level, network access control policies should be set so as to limit, as much as possible, connections of database servers with their respective application servers. Note, however, that network access control policies should not prevent customers from implementing valid node-checking in their databases.
On a related topic, native network encryption and SSL/TLS and strong authentication services (Kerberos, PKI, and RADIUS) no longer require a separate license and are available in all licensed editions of all supported releases of the Oracle database. Database customers should take advantage of this licensing change to enable network encryption and, if possible, strong authentication. A similar hardening approach should be used between applications servers and web servers when the applications are exposed to the Internet. Tightly controlling subnets around critical systems and controlling how systems can connect with each other bring organizations a long way toward maintaining a good security posture.
Multidimensional thinking should not be limited to technical issues affecting the IT environment. Multidimensional security thinking should also apply to the organization overall. For example, the human factor remains one of the weakest links from a security perspective. Organizations generally train staff about what constitute good passwords, but do they sensitize staff to social engineering issues? Ongoing security training for all staff is necessary for the organization in the same way that firewalls and traditional security technologies are required.
So where do you start when you need to reassess the security posture of the organization? Start with the basics: know your systems and who uses them. Try to think like a hacker and question closely-held assumptions and technical silos: malicious hackers will not feel bound by technical diagrams and organizational expectations of how systems will be accessed. By all means, take advantage of the various security methodologies and frameworks, but do not get caught exclusively in a policy documentation or audit exercise. Periodically assess your security readiness, and when appropriate do selective pen-testing (keeping in mind that demonstrating how to break a window does not necessarily help you safeguard the entire house). Understand the security assurance practices of your strategic vendors as they will have great impact on the security posture of the organization. And of course, keep up with releases and Oracle’s Critical Patch Updates. Obsolete and unsupported versions, regardless of their initial vendors, can become ticking time bombs, as security patches become no longer available, but exploits for these systems become widely known (and scripted into hacking tools).