Information Security Management Part 1: Beginning Your Journey
When Unicon was founded almost 30 years ago, information security wasn’t as serious an issue. Hackers existed, but were more curious than malevolent and caused mischief more than damage. Unicon was a pure Unix consultancy then so we understood computer security very clearly, but there just wasn’t a compelling need for a company security program.
Today, of course, bad actors abound and a well-formulated security program is essential. It’s important to note, though, that the path to a secure business is a journey and not a destination. Information security is constantly morphing, so the commitment to security must account for continuous effort as you begin creating a security program of your own. I will take you on a tour of my security education over the coming months through a series of articles in which we’ll investigate the following:
- Starting a Security Program
- The Pillars of a Program
- From 0 to 27001 - The Growth of a Security Practice
- Security Is Only Limited By the People Who Practice It – Security Awareness
- How to Think About Risk Like a CISO
- How to Run an Information Security Evaluation
- Remote Worker Risks – What’s Different?
Our own security journey began when we hired a senior executive who had vast experience at larger firms with very specific cybersecurity demands. He quickly noted that we were very particular about computer security for our clients and our own data, but there was no formal business practice around risk management. We were sound tactically but lacked strategy and formality. Thus began our security journey and our commitment to making information security a core business principle.
Like most new undertakings, the journey to better cybersecurity might seem overwhelming at the outset, but like any journey, the key is to map out your path. There is no wrong route, and many paths lead in the right direction. Our journey started with the following steps which might help you chart your path as well:
- Define your core business and the scope of security program - get management buy-in
- Enumerate the essential (existential) risks to your business
- Assign risk measurement (probability x impact)
- Look at standard frameworks - do any offer guidance that fits? (CIS Benchmarks/Top20, CSA Controls, NIST, ISO 27001)
- Take stock of prescribed existing policy and process and identify obvious gaps
- Assign ownership/stewardship and create a maintenance plan
Scoping your program should be your first step. In our case, we wanted to include every aspect of our business, but your scope may be more limited. For example, when we began our process, we had two locations and wanted to include both as well as all our lines of business. If your business purview is sufficiently broad, you might reasonably choose to limit the initial scope of your program to just one service or product that you feel represents the most exposure to the firm, and grow it over time.
The whole purpose of an information security program is to eliminate or mitigate risks to the business related to your valuable data. Your executive team already has a list of risks that could harm or even quash your business. You need the information security equivalent. List everything you can think of that could affect the confidentiality, integrity, or availability of your data (and consequently your business). Think about things like a ransomware infection caused by someone clicking a bad link or a lost laptop that wasn’t encrypted and contained sensitive data. Don’t limit yourself to the obvious though. Think of physical security issues that could be damaging (a visitor views confidential data on an unlocked screen) or a disgruntled employee exposing data. Be creative and grow the list over time. Remember to revisit this list again and again. Use it to track things like a risk you have to accept because of decisions beyond your control.
Rate the Risks
Once your risk registry is complete, assign a risk level to each item. You can use a numeric scale or just something subjective like low/medium/high. To make things a bit more rigorous, though, you might assign a numeric value and then translate that to a category. One formula for risk is:
Risk = Probability x Impact
Say you use a scale of 0.00 to 1.00 for probability and 1 to 10 for impact and let’s take the ransomware example from above. You might see it this way:
Probability of occurrence in the coming year is 0.60 (a little higher than 50/50)
Impact from such an occurrence would be 8 (the business could potentially be halted for some days)
Risk = 0.6 x 8 = 4.8
We can see that the lowest value we might have is 0 x 0 = 0 and the highest 1 x 10 = 10
So our scale is 0 to 10. Let’s break that up into qualitative categories:
|Subjective Category||Risk Calculation|
|Low/None||0.0 through 0.9|
|Minor||1.0 through 4.9|
|Medium||5.0 through 8.9|
|High/Certain||9.0 through 10.0|
So our example above has an overall risk category of Minor. However, don’t feel constrained by this result. In security, we will typically “temporalize” our findings to suit our specific environment. That is to say, we accept the calculated value, but that represents the risk from a randomly selected employee that could range from a business development representative to the CFO. If we want to state this risk in terms of the worst-case scenario, we might move it up to the Medium category since the event happening to the CFO could be considerably more damaging. Remember, the objective is to assess the risk you perceive, not some random number derived in a vacuum.
Select a Framework
Now you know what you are trying to prevent through your security practice. It’s perfectly reasonable to simply start crafting documents that lay out the policies and processes needed to make this happen. You might craft an employee security policy that states things like “all employees will maintain anti-malware protection on their computers” and “all employees will assure that backups are performed regularly and successfully” in order to protect your important data. However, this approach makes it easy to overlook gaps. It’s a much better practice to adopt one of the many recommended frameworks that professionals have evolved over time. Some you might consider are:
- CIS Benchmarks or the CIS Top 20
- CSA Controls
- NIST Cybersecurity Framework
- ISO 27001
This list runs from basic and very understandable to elaborate, thorough and more challenging to implement. I would recommend starting with the basics and working forward. You don’t need to address every risk at one time. In fact, studies indicate that implementing just the top 5 controls in the CIS Top 20 will address 80% to 95% of all known vulnerabilities. Viewed another way, you can eliminate roughly 90% of your security risk with a very modest investment of energy. Use this to your advantage and grow your practice over time.
Identify Documentation Gaps
Now that you have a framework to measure against, take a look at the policies you already have crafted and look for gaps. Get your key documents together first. The ISO 27001 standard has a list of required documents you can measure against. There are any number of sites that condense the standard down to a simple list and one of my favorites is from Advisera. (Note: neither I nor Unicon have any affiliation with this company. I have simply found them to be a good source for understanding the ISO 27001 standard). This list represents the needed program documentation in total and to certify to the ISO standard. You are, by no means, required to have them all if they don’t add value to your program and you don’t care to get ISO certified. Don’t get bogged down in creating it all from the start. Think about what policies will be most helpful for the employee base and senior management. Start with those. Think:
- Corporate Security Policy
- Employee Security Policy
- Data Classification Policy
- Access Control Policy
- Any other baseline documents that create a foundation for your needs (every company is different, but there are always commonalities)
Get the necessary documentation together and make sure you have support from senior management for the expectations and requirements captured. Having the support of the executive team in creating your cybersecurity practice is vital or your effort is doomed to failure. Also, get the appropriate executive to approve each policy. While not vital, it will ultimately be required if you move on to more formal certification exercises, and it lends weight to the policies and processes you will present to the rest of the company. Recognize that this step is never complete. Your security requirements will change over time. New legislation, customer expectations, changes to the business model and all the things that make running a business challenging and exciting will necessitate constant evolution. Part of your primary corporate security policy should be a requirement to review your policies regularly (annually is pretty common) and adapt them as needed.
Ownership and Maintenance
This final step is absolutely essential. You must assign someone ownership and responsibility of the overall program. This doesn’t have to be a single individual, although I recommend that. The program itself can be supported by a cast of characters and probably needs to be in most cases, but a single guiding principle for the practice may prove vital. As mentioned at the very beginning of this article, the journey to cybersecurity is not a march to a destination, but rather a process. It’s important that there be a guide for this journey and some authoritative individual answerable to the programs successes and shortcomings. This is not to create a point for blame or praise, but rather a primary support point that will not allow the practice to falter or, worse yet, fail. You will be putting considerable energy and resources into this effort. The worst possible outcome I can think of is to allow all that effort to be wasted. Additionally, ownership creates a place for senior executives, (remember that their support is critical?), to look when they want to understand what’s at risk, how challenging that risk is, and how best to mitigate or eliminate it. Really, though, the expectation here is not different from any other project. Someone needs to lead, coordinate, delegate, and execute in order to make progress. Your security practice is no different.
So, I’ve demonstrated that an organized approach to any security journey doesn’t need to be a complex and burdensome task. It can be broken down into some relatively easy chores that allow the resulting program to grow and evolve over time. This allows the guide to take on manageable bits of work that lead to substantive results. Simply chart your course to scope your effort, discover your security risks, assign them priorities, select a map (framework) that others have shown works well, figure out what you already have in place, and elect someone to own the program going forward. Don’t forget to involve your senior management team early on so that they understand the value this adds to the company and definitely reach out to Unicon if you need a companion along the way. We’ve been down this road before.