Information security architects use documented frameworks to codify key practices, technologies, objectives and other elements relevant to the organization's security or risk management program. While there are clear benefits to creating and following such frameworks, we need to be mindful of the risks of adopting them without hesitation or customization.
Example: Marketing Strategy Frameworks
The notion of frameworks is present in many industries. For instance, among the marketing frameworks taught in business schools is one called Four P's. Designed to assist in evaluating a marketing strategy for a product, it advises businesses to consider the following elements:
- Product: What is the product?
- Price: How is the product priced?
- Place: Where or how will the product be purchased?
- Promotion: How will the customer find out about the product?
Another framework speaks of four C's—Commodity, Cost, Channel, Communication—as important elements of a marketing strategy. Yet another framework, called STP—Segment, Target and Position—advises how to focus the strategy on the appropriate parts of the market.
These, and many other frameworks sound insightful. Yet, it is unclear that a one person's framework is more useful than another's. Dan Ariely, a behavioral economist, discusses in the following 5-minute video how he led a class of executive MBA students through a discussion that used two arbitrary frameworks that he made up without the students even questioning the frameworks' wisdom.
The moral of Dan's story is that it's easy to force the world into some framework without understanding the nuances of the situation and without evaluating the framework’s usefulness.
Information Security Frameworks
We love frameworks in the world of information security, too. We have standards, such as ISO 27001/27002 and PCI DSS, regulations such as HIPAA and FISMA, as well as lots of designs, templates and guidelines often grouped under the heading of best practices. Too often, companies attempt to adhere to these frameworks without understanding their applicability and limitations.
For instance, PCI DSS is pretty prescriptive about its security requirements. Yet, organizations often misinterpret them in a way that suits their budgets and business practices. Some companies even attempt to adopt PCI DSS as an approach to securing non-PCI environments without considering the extent to which the threats and security practices might differ.
As another example, consider the numerous controls listed as part of ISO 27002. Companies, possibly earnest in their desire to build a information security program, attempt to implement all of them. They do this despite ISO 27001 advising that the controls' applicability depends on the organization's "needs and objectives, security requirements, the processes employed and the size and structure."
A related concern is regarding our reliance on advice labeled best practices. These frameworks, according to The New School of Information Security, are "activities that are supposed to represent collective wisdom." The book warns against relying on them blindly, in part because the groups codify them have vested interests in security decisions. The book also points out that best practices "typically don't take into account differences between companies or, more importantly, between industries."
Usefulness and Dangers of Frameworks
Frameworks aren't magic. They are put together by individuals like you and I, who usually do our best to codify our experiences and relay advice to other practitioners. This can help by providing a structure for making risk decisions, achieving compliance and thinking about hard security problems. However, we must be mindful about the dangers of blindly following frameworks without considering how they apply to a given situation or customizing them to the specific needs of the organization.