Talk to a Security Expert Now: (800) 721-9177

Focus first on IT security goals, compliance will follow

I was depressed earlier this week from conversations with a security vendor and a system developer. They both had developed, more or less, the same point of view. The security vendor said, “Compliance is what sells”. The system developer said, “Failed audits are what can get the attention of management.” Compliance is certainly necessary for most companies, whether driven from the standpoint of adherence with internal policies or government regulations. In many cases compliance requirements have provided the impetus and funding for a first class information security program. The problem is that compliance does not necessarily lead to security. Ask any shareholder from TJX.

So then what path can be taken assure security for a given business? Unfortunately, there are no silver bullets available at any price (ask Google). However, structuring a continuous security management process around several important elements can yield results that strengthen the business both qualitatively and quantitatively. These key elements include understanding the threat environment, designing security in as a systems requirement, managing risks and winning the economic contest with adversaries.

For this discussion we’ll focus on security goals and designing security in as a system requirement. In this case the systems we need to consider are not just applications but the networks, policy enforcement points, virtual machines, and servers that support them. Security goals consist of the following:

• Authentication
• Authorization
• Confidentiality
• Data/message integrity
• Availability
• Non-repudiation
• Accountability

These need to be defined in terms of specific, measurable and documented requirements. As such they become features of the overall system, but also contribute to a larger set of processes by which the system is developed, tested, deployed and maintained. Without shared understanding of security goals and requirements among stakeholders such as developers, architects, testers and operations staff, the business is put at risk and efforts to add security after the fact will be frustrating if not impossible. As an example of what not to do, consider the Microsoft SMB protocol. Security goals were never established in initial versions. Later versions still suffered from deficiencies ranging from lack of documentation to no requirement for client authentication to highly complex cross-domain deployment. Today at least 12 dialects of SMB exist that continue to offer attackers a rich target. Over time, Microsoft has emerged as a major proponent of security goals and designing in security, but there are innumerable legacy systems out there where the damage has been done.

What then is the optimum path to a secure and compliant business? My recommendation is to start with security goals, build processes from aggregated goals associated with the business critical systems, adapt internal policies to support the security goals and then extend internal policies to comply with regulatory requirements. Working the process in reverse, starting with compliance to regulatory requirements, means clear security goals may never surface. Without the foundation of security goals for the systems that support the business, security policies and processes are difficult to manage, internal and regulatory compliance is costly to maintain and the business is put at risk.

Leave a Reply

Your email address will not be published. Required fields are marked *