Top-down Security Deployments for Success

Many organizations struggle to implement security controls and technology within their enterprises due to a very common management error: failure to use a top-down approach to deploy security solutions.
First, what is a ‘top-down’ approach?
In the field of Strategic Management, a top-down approach relies less on subordinates for planning the vision, mission, and strategic goals of a project, and more on leaders at the top of the organization, who then communicate the goals to the ranks below.  Those on the frontlines then translate these strategic goals into tactical goals and execute on them accordingly.
Contrarily, a ‘bottom-up’ management approach relies on the expertise of the lower ranks to assemble data to formulate the tactics and strategies, and present it to the upper ranks for action. An example of this approach might be a budgeting process, where IT workers request a specified dollar amount to build infrastructure. If the organization’s management had created an arbitrary budget without taking into account their knowledge, it’s unlikely the budget would meet the requirements.
Top-down and bottom-up approaches both have their place and time, but when it comes to the implementation of regulatory and compliance security, the top-down approach is more likely to successfully achieve the organizational goals. Here’s why:

• Without known consequences, many security initiatives are doomed to failure. Take for example credit card security.  Many security admins had a hard time getting their organizations to pony up the budget for encryption, WAFs, security scans, firewalls, IDS/IPS, etc.  Since PCI was implemented, which provides a basis for top-down security management, we’ve seen the purse-strings loosen for admins requesting budget for security technology. Why?  Because the business suffers if PCI compliance is not obtained and maintained. Finally, top management had a  mandate that required that they put the proper security controls in place to be PCI-compliant.
• Organizationally, lateral monitoring and auditing doesn’t sit well with employees. Many departments and teams can be entrenched in their spaces, and somewhat territorial when it comes to their roles.  It’s a challenge to get them on-board with being monitored or checked for security compliance, particularly with the different personalities that exist between DBA’s, developers, enterprise admins, and auditors. Asking a team to implement and enforce security and audit compliance on other teams that are lateral in the corporate hierarchy causes confusion about who the project champion is, the criticality of the initiative, and the understanding that the executive leadership is behind the initiative.  Pushing the goals down from the leadership gets everyone on the same page and reiterates the corporate security messaging.
• Significant cross-departmental dialogue is necessary.  Asking a security admin to forklift a major security project into place without coordination with other departments is likely to wreak havoc in the organization.  Many times, Change Controls will need to be coordinated, which generally involves signoff from multiple entities such as Network Operations teams, DBAs, Application Admins, and other stewards of IT.  Having a lone admin trying to push impactful projects through the organization without signoff from management will generally raise red flags.  However, having an executive project sponsor and formalized project management would provide the visibility needed to coordinate across different organizational functions.

Now that we’ve defined what top-down management is, how does it apply to SecureSphere deployments?
Great question.  First off, many Imperva customers purchase SecureSphere to meet compliance and regulatory obligations such as PCI, SOX, HIPAA, etc.  Organizations should have a solid understanding of where they stand in terms of meeting those obligations, as many of them deal with the organization as a whole and are not specific to one area.  A Compliance Officer should understand which regulations apply to their business, what tools they have to meet those obligations, and what the ‘gaps’ are.  Once the gaps are defined, a suite of tools or processes to fill those gaps is generally identified and implemented.  If an admin is left to his own devices, he may not monitor sufficient data to meet those goals. Certain features may be enabled or disabled that prevent compliance from being achieved.  Contrarily, an admin may monitor too much data, driving up the costs of the project unnecessarily.  A top-down approach to security would have already defined key goals for the SecureSphere deployment based on discovered compliance gaps.
Some of the areas that top-down security goals defined by Compliance Officers would translate into when it comes to specific SecureSphere configuration settings are:

• Which systems are within scope and need to be protected. This translates into a Site Tree within SecureSphere.
• Which data needs auditing. This translates into Table Groups which are populated by Data Classification Scans or are manually populated.
• What operations need to be audited.  This translates into Audit Policies and the DB Operations that are taking place. For example, is it necessary to audit ‘Update’, ‘Insert’, and ‘Delete’ in addition to ‘Select’ operations? What about ‘Privileged Operations’?
• What level of protection the asset needs. This defines the Security policies used in SecureSphere.  For example, is Profiling and Signature matching necessary, or will Audit Policies suffice?
• Record retention rate. Defining how long the audit data should be retained is achieved using the Archive and Purge functions of the Audit Policies.
• Reporting.  Which reports are run, on which data, and viewed by whom are defined in the Reporting section of SecureSphere.

Organizations that use a top-down approach to deploying SecureSphere will have a higher chance of successfully meeting the goals of the organization.  Additionally, the TCO will be lower since storage costs for regulated data to satisfy the audit will be smaller, labor spent on unnecessary processes will be eliminated (i.e., discovering and securing out-of-scope data), and cross-departmental goals will be aligned, reducing the impact and risks of implementation.