The IT Process Institute conducted a study and found that out of 53 analyzed controls, these 12 controls account for 60% of the IT controls that impact performance.
A defined process to detect unauthorized access
Defined consequences for intentional, unauthorized changes
A defined process for managing known errors
A defined process to analyze and diagnose the root cause of problems
Provide IT personnel with accurate information about the current configuration
Changes are thoroughly tested before the release
Well-defined roles and responsibilities for IT personnel
The defined process to review logs of violations and security activity to identify and resolve unauthorized access incidents
A defined process to identify consequences if service level targets are not met
A defined process for IT configuration management
A defined process for testing releases before moving to the production environment
CMDB describes the relationships and dependencies between configuration items (infrastructure components)
So, instead of spending all of your time trying to "comply" with extensive Framework control requirements, this study suggests that you focus your attention on specific activities in the areas of access controls, change controls, release controls, configuration controls, resolution controls, and service level controls.
There are hundreds of security frameworks available across the globe for a company to choose from and none of them are a one-size-fits-all solution to your security needs. The challenge is that all businesses are unique, and their security needs are determined by their tolerance to risk and by the external compliance requirements dictated by their industry and often their geographical location. A healthcare organization will choose a HIPAA compliance-based framework, a credit card company will choose a PCI-based framework, and a power company will focus on a NERC-based framework. And, if all they did was follow the framework controls requirements to build out their security baseline they would still fall short of securing their organization.
The fact is, there’s no right choice here. Frameworks are just frameworks. They’re a guide. Their purpose is to help an organization put together an approach that won't land them in the news or in a big lawsuit. They’re extremely valuable and necessary. Still, depending upon where you are in your security plan development process they can be overwhelming and lacking a clear tactical approach on “how” to secure your organization or even where to start.
The important thing is that you have a methodical approach to securing your organization. You do not need to be an expert in information security, IT operations, or project management and you don’t need expertise in any of these frameworks to implement a baseline security program. But, you do need to understand your business risks and the controls necessary to mitigate them.
“But, I’m supposed to comply with compliance requirement XYZ!”. I hear you. And, yes you do…eventually. But, first, make sure that your foundation is in place before you run off down a reactive security path chasing after audit findings that give only the illusion of security.
If you want to study frameworks, don’t get lost in the weeds. We’re trying to see the forest first. However, if you’d like to know more about the different flavors of security frameworks I’d suggest starting with NIST 800-53 r5. If you'd like to request access to the NIST 800-53 Mind Map fill out the form above and we'll email you the link. Check it out!