Saturday, August 18, 2012

Vectors of Information Security


Within the realm of information security, a lot of focus is paid to the vectors of attack. Essentially how an attacker can go after your networks, systems, people and information. These vectors focus on how the attacks can occur, how to detect and respond to them. But they only hit on part of the challenge in securing todays complex information technology (IT) environments.
Vectors of Information Security start with a definition of what behavior is allowed and then monitor and react to anything outside of that defined criteria. Most information security policies state policies in the form of “Administrators will deny access to those not allowed”. In the form of VIS, we will say that “Active employees are allowed access” and respond to all access outside that form. This is a variation of the security models focused on policies based on denying access and is a change in mindset for many security professionals.
More critical then the vectors of attach, are the overarching Vectors of Information Security (VIS). These correlate to the overall usage of information and allow Architects, Administrators and IT Leadership to plan accordingly for information access and risk management around expected usage patterns. The three Vectors of Information Security are:
  • Paths of access – This category focuses on all the tools, technologies and applications that allow access to a corporation’s data. This includes both data in transit and data at rest.
  • Paths of change – This avenue is for documenting and understanding how information changes; information can include access logs, configurations, customer information and financial information, just to name a few.
  • Paths of risk – This is the category that vectors of attack will become part of. Path of risk is the likelihood that an unknown, unacceptable or unanticipated event will occur and the associated cost to the organization for the incident.

Information security is about risk management and mitigation. The Vectors of Information Security enable organizations to outline clear policies for understanding, managing and responding to the risk that is inherent with todays interconnected systems.

Tuesday, August 7, 2012

Understanding Security versus Compliance


I have been in a variety of projects over the years that mixed the use of the terms security and compliance. Often using them interchangeable. While some implementation details are common for both, the end goals of security and compliance are very different.
I have worked in a variety of environments that combine security and compliance from a functional and operational standpoint, and while this often makes sense from a resource perspective, it is critical to ensure staff understand the differences between security and compliance. Plainly put:
  • Security is about ensuring that only those authorized can obtain access to resources and there are mechanisms in place to alert when events outside the norm occur.
  • Compliance is about ensuring that implementation and operation of the environment follows all corporate policies, industry standards, and regulations; and that exceptions are clearly documented.

The short answer is that you can be compliant and non-secure; you can also be secure but non-compliant. This is the catch-22 that must be balanced for the staff tasked with implementing and monitoring corporate policies. When planning your corporate security standards, it is important to ensure that compliance teams have a seat at the table, and vice versa for compliance planning. This cross team support will ensure alignment, no duplication of efforts and understanding of what each team is trying to accomplish.
The best case is that a companies compliance policies mirror the IT policies for security and access controls, this ensures that monitoring of the environment and implementation is as light weight on staff as possible. By ensuring a level of consistency in the security implementation, compliance regulation can be proven more quickly, with fewer resources and with less rework of the environment as requirements and policies evolve.