Define security policies and procedures – and you will be able to demonstrate compliance. But you need working capabilities to make a real impact. Read on to see how to achieve more security in less time using agile security approach.
A couple of years ago, I was reviewing the security of one of the company suppliers. Before we started our audit meeting, the team presented me with their ISO 27001 certification. The Security Officer asked me whether the review was necessary because they developed multiple policies, procedures and instructions comprising the information security management system, and its successful implementation was confirmed by obtaining the certificate. However, after a couple of recertification audits, they stopped maintaining their security program.
Why – I asked them. The CISO replied that this was because management decided that their security framework was perfect enough, and it did not have to be improved anymore.
After completing the first round of interviews, evaluating some elementary evidence, I was almost sure that all those procedures did not have any value. Virtually no one in the organization was following them. They were outdated, and they were useless for most of the employees. So the people invented other ways of conducting work, but without too much focus on security.
I was able to notice that pattern also in other organizations. When there is too much focus on comprehensive documentation and compliance, people have little time left for implementing practical security.
Working capabilities over documentation
Each of the security capabilities needs a set of components to be operational. In most situations, I define them based using a bit simplified version of the enablers described in the COBIT Framework. For each security domain, we usually need the following types of items.
Components of security capabilities
Traditional approach
The traditional path to establishing a security capability covers the following steps:
- Conduct a comprehensive risk analysis,
- Select the required controls,
- Set up the organizational structure,
- Document policies and standards,
- Design and document processes,
- Establish information resources,
- Procure, customize and implement tools,
- Train the people,
- Implement supporting services.
Unfortunately, there are a couple of challenges with this action plan.
Challenges with traditional approach
Alternative approach
I believe that there is a different route you can take. You can use an agile mindset that produces tangible results faster. And by those results, I mean working capabilities instead of piles of papers provided only for the compliance purposes.
Table of contents
Use a light approach to risk management
The main objective of risk management is not to catch all the details of all organizational assets, analyze all of the potential vulnerabilities, evaluate all of the possible threat scenarios and conduct elaborate calculations. You can take more pragmatic steps to finalize your risk assessment.
Simple approach to risk management
- Group your assets into categories with a similar risk profile,
- Focus on your crown jewels where impacts are highest,
- Limit the number of analyzed threat scenarios,
- Conduct a high-level risk analysis to select areas of focus,
- Move quickly to the selection of required controls,
- Prioritize security domains you need to implement or transform.
This method supports a fundamental purpose of risk management – selecting controls that help to manage unacceptable risks. The sooner you get there, the sooner you can focus on real action that impacts your risk exposure.
Define only mandatory policies
Document necessary policies and standards. Use them to outline controls and requirements. One information security policy that includes a set of domain-specific standards is often enough. You do not need separate policies for risk management, access management, business continuity and other twelve or twenty security domains you identified. The more policies you have, the harder it is to maintain them and ensure they are consistent between each other.
Focus on solutions first
Do not put too much effort into documenting every piece of security reality. You can spend your time better by concentrating on selection and implementation of essential technology solutions. Implement necessary functions first that help to manage the most critical risks. Test them on a smaller user population. Gradually expand your coverage. And only after that, you can introduce additional functionality or include new use cases.
Adapt processes to available solutions
The conventional strategy for implementing security technologies assumes that we need to define business and technical requirements first, design business processes, select one of the systems, implement it and customize it. Or build our own. The objective is to adapt the software to the processes we design, so they reflect them in 100%.
However, in reality, it does not work very well in case of complex security solutions like Information Rights Management, Data Loss Prevention or Identity and Access Management. The customization is usually too expensive and takes too much time.
The more practical tactic is to adapt your security processes to technologies which are currently available on the market. Simply choose something that covers 80% of your specification and adjust your operations to the selected platform.
I know, it might sound like a heresy. But think about this. Take Identity and Access Management solutions as an example. What is more beneficial? Building and maintaining your own IAM system to ensure it can integrate with 200 of your applications in 30 different ways? Or selecting a solution available currently on the market that will cover 100 of applications already integrated with your Active Directory domain? Something that will help you to manage 70% of the user population in the first phase? And then spending the time you saved on integrating remaining applications with your domain and the IAM at the same time?
What is more efficient? Spending millions of dollars on complex IAM customizations? Or spending some time on simplifying your too complicated access management processes?
Favour automated controls
Do your policies require the users to lock their computers when they go away from their desks? I believe so. Does it always work? If yes, why so many of us are implementing automatic screen savers with passwords? Why there are some many invitations to the parties sent by people who left their computers unattended? The reason is simple. When people make mistakes, we need automated controls that help to detect or correct them.
The second reason is that the documentation is not feasible for all situations. Some of the requirements change too often and are too hard to maintain in a documented form. It is more practical to develop golden images and install configuration monitoring tools instead of writing specific technical standards for each operating system. It is more feasible to require developers to use benchmarks available on the market and implement code review tools instead of spending months on composing complicated secure coding guidelines for each of the language or framework used by your organization.
Document required processes only
I am not an enthusiast for writing procedures for everything. If the control does not require execution of sequenced activities to produce expected results, it is not a process, and supporting it by a procedure is worthless. If the control is strictly technical and is related to a specific configuration setting, you do not need a procedure to implement it. Just make sure someone will take care of it. And have a monitoring tool in place that checks it is done and alerts in case of unauthorized changes.
Which security processes to document
- Comprising of numerous actions,
- Executed by various stakeholders,
- Expected to be formalized by relevant regulations.
Use automated workflow systems
Documenting your processes does not have to be always in the form of a traditional word processor file published on your company intranet site. Much more efficient way it to use workflow management tools available on the market. Using them, you can define your processes and automate them. Automation ensures that the processes are executed in the way you envisioned, all required information is captured and all approvals are in place.
Most of those solutions work with process maps that you can export later with descriptions in a form similar to traditional procedures. In this way, you can have the working capability first, and you can export documentation whenever this is necessary.
Develop simple documentation
Most of you will not read this post from the beginning to the end. Most of you will just scan through its content. It is because of the way our minds operate in times of constant distraction. And I understand it. I believe that you should also accept the fact that almost no one is going to read 30 pages with small print and long paragraphs about information classification.
Develop one-minute policies, simple procedures and simple instructions dedicated to essential tasks. Ensure they are also easily readable – with clear sections, headings, short paragraphs and numbering.
Use modern policy management tools
Word processor documents, sometimes even printed, with separate title pages, history of all changes, details of approvals and definitions inconsistent between multiple policies – this is still the reality of many organizations. Those approaches are hard to maintain. Today we have better options. Wiki pages, collaboration platforms and similar solutions work much more efficiently.
Benefits of modern policy tools
- Maintain links between related documents,
- Hide unnecessary details,
- Present information in a standardized way,
- Automate approval and review workflows,
- Keep administrative data out of sight,
- Implement the changes quicker.
All of that makes your documentation more user-friendly. Remember that the documentation should be as usable as possible for your employees – not auditors. If they come, you can always export everything they need in a more traditional form.
Summary
The examples presented above come from the projects completed in various companies in different industries. There is no guarantee that they will work in every situation because they depend on the unique organizational context. However, I can only urge you to utilize the agile approach – test selected techniques in your security projects, observe the results and adjust if needed.
