This is the final of three posts on the CIS Critical Security Controls. If you haven’t already read the previous two they can be found here (part one) and here (part two). There are only four controls in this section, so it should be a shorter read this time!
This post will focus on the Organisational level controls (sorry America – I refuse to spell it with a z!) which are more policy and process orientated than the previous two sections. Processes and policies are as equally important though – technology alone does not provide a robust security posture. You can implement all the tech you like, but if you aren’t following up with adequate training programs etc. then you are doing the technology you invested in an injustice. Policies can help provide a point of reference for administrators and users, ensure that senior management is on-board with what you are doing and help by providing you the opportunity to sit and think about what it is you are trying to achieve.
17) Implement a security awareness and training program
This one is hugely important in my opinion. Us fleshy things at the end of the keyboards are more often than not, the weak link in the security chain. From clicking on phishing emails, to browsing dodgy sites and sending sensitive data over insecure channels – there are a lot of things that can go wrong when there is a lack of understanding/awareness.
Adopting a positive culture of security awareness and training is vital to improving your security posture. Security should be something everyone thinks about and not something they consider to just be a burden. Of course, there is always the possibility of resistance to certain things, particularly if it has “always been that way” and you try to change things. But if you explain to your users why you are doing certain things and why it matters they will hopefully be more understanding and receptive to change. Just deploying new technology and telling people “you will use this – because security” is not likely to work too well.
The control calls out identifying your skills gaps, putting together a training plan to remediate said gap and ensuring that you implement an organisation-wide security awareness program. I’d emphasise the organisation-wide piece of that sentence. Don’t assume certain users (such as those in technical roles) know stuff already. I’ve met some really smart technical people over the years, but not all of them necessarily understood security and how it mapped to the role they carried out. As with anything security related as well, your training/awareness programs need to change and adapt over time. They should not remain static.
Some of the areas specifically called out for training include secure authentication, identifying social engineering, handling sensitive data, causes of unintentional data exposure and identifying and reporting incidents. They may seem obvious to you, but they aren’t necessarily to others. Don’t forget, that training in these areas can help people in their own personal lives as well. The same things they learn to protect the organisation can help them on a personal level and it can be useful to sometimes help try and sell this aspect of the training programs too. Encourage people to feel comfortable with reporting potential security issues and emphasise they are not going to get into trouble – it is much better to know about things and deal with them, than to try and hide or ignore them.
18) Application software security
Not as applicable to all organisations as some of the previous controls we have reviewed. This one is likely more geared to organisations who are coding applications, but there are still some points all organisations can take away from this.
For organisations carrying out their own coding it is hugely important that secure coding practices are followed from the outset. Too often, there is a gap between developers and security until the end of a project when perhaps it will get a quick vulnerability scan. The amount of vulnerabilities in web apps that still result in compromised sites though is huge – so clearly something is going wrong. Are your developers appropriately trained in secure development practices? Are you pulling in third-party components in to code? Are they still supported? Do you keep track of them and where they are used?
Take the huge Equifax breach back in 2017 – this was entirely preventable and ultimately due to unpatched Apache Struts software. There are tools out there that can help this, from things such as inventory systems that keep track of the components used in applications, through to tools that integrate into your IDE (Integrated Developer Environment) that will automatically warn you when you are trying to use out-dated or vulnerable components.
Code analysis, error-checking, penetration – this list goes on. The point is to try and really ensure the application has been properly tested before exposing it. And don’t assume that even if you do all of this that you have a rock-solid app and you can forget about it. Vulnerabilities likely do still exist, and you need to provide people with a clear way to report them to you. One proposed standard can be found at https://securitytxt.org/ and is something I’d recommend all organisations to do – even if you only host a static corporate website. For some of the larger more application heavy organisations you perhaps want to consider looking at bug bounty programmes such as those offered by the likes of Hacker One – https://hackerone.com.
Other things called out in the controls (which are applicable to a lot of organisations) are things such as separating production and non-production systems, limiting developer access to production systems, using hardening standards/templates and considering the use of Web Application Firewalls (WAFs). If you’re not familiar with WAFs – think of them like an Intrusion Prevention System specifically geared towards protecting web applications. They are not an excuse for lazy coding or sub-standard patching though. They are there as part of a defence in depth approach!
You’ll notice aspects of this tying back into earlier controls such as the basic “Continuous Vulnerability Management”. The point here is that the most effective way of tackling this is from the cradle to the grave. Security needs to be woven into the entire software development lifecycle.
19) Incident response and management
Assume you are going to be breached. If you’re reading this thinking “Pffft… nah. Ain’t gonna happen” then you are probably being naive. Security is hard. There are so many components across so many systems and a lot of financially motivated “bad guys” out there! This control is all about ensuring you do the planning up front to save you running around like a headless chicken when the proverbial waste material hits the air circulation device!
This heavily ties back to having good visibility in your environment and applications. To be able to respond to an attack or breach, you first need to be able to identify it. Once you have identified it you need to have a defined response to it. A response that is going to help you contain and eradicate the threat you are faced with.
The control calls for documented incident response procedures, with specific defined roles and responsibilities. That way when time is of the essence you can just get on and respond, rather than working out who will be doing what and losing precious time. With any kind of response plan such as incident response or business continuity it is important to periodically test and evaluate them as well. This can range from just reviewing the document to ensure it is accurate, through to table top exercises and full on simulations. The whole point of testing is to ensure people build that “muscle memory” of what to do and you can identify and resolve areas for improvement.
You are not going to be able to prepare for everything – there will always be scenarios people can never foresee. But you can certainly prepare for many common threats that you could face. One key thing I’d add that isn’t specifically called out is around communication. It is easy when people are in the middle of a crisis to forget this and either send out no or incorrect information. Have key roles that will handle communication at defined intervals and ensure they are fed with accurate information. One thing you don’t want to do is overburden the people trying to respond and distract them from what they are trying to achieve.
20) Penetration tests and red team exercises
This control is all about taking an offensive approach to your security. Have people put themselves in the shoes of the “bad guys” and see what they can achieve.
Though a common term, you may be wondering what a red team (and its accompanying term – blue team) is. In simple terms, think of your “blue team” as your defenders – your security engineers, your SOC analysts, your incident responders. The people in your organisation trying to keep you safe from threats. Red teams are people who are trying to actively attack your security and test your blue team’s detection and response capabilities.
Wait… so red teams are the same as a pentest?
Not quite no, though you may hear the two terms used interchangeably. I wouldn’t get bogged down in the differences, but in short pentesting is aimed at trying to find as many vulnerabilities in something as possible. So perhaps you have a public facing website – you want to identify all the possible issues you can. Red teaming is more about taking a stealthy approach and trying to behave like a real attacker. They are usually longer engagements with a team of people trying to compromise your defences with a specific goal in mind, whilst also trying to evade your blue team’s detection just like a real attacker. It is a way of identifying gaps in your controls, monitoring and other processes. Red team engagements are really only designed for those who already have a pretty mature security model, whereas pentesting is applicable in some way, shape or form to most organisations.
The control recommends the adoption of a pentesting program that aims at targeting a blend of different attacks – for instance not just necessarily your web applications, but perhaps other things like VPNs, wireless connectivity and client systems. They should be conducted regularly, particularly where you have external facing systems. They are not recommended as a replacement to vulnerability scanning/management tools, but often the results of the latter can help feed in to pen-testing for a more targeted approach.
Whilst it is impossible to fully secure any system and remove all risk, actions outlined in this control can help you identify and remediate issues before someone else does.
So that is it. We’ve had a brief look over the CIS Critical Security controls. I’d strongly recommend you download and review the full document at the following link - https://learn.cisecurity.org/20-controls-download and start to consider how they can help bolster your security. Start with the basics and then take it from there. It isn’t to say you have to implement all controls – at the end of the day security is there to enable a business and the cost to implement controls has to be justified. You wouldn’t spend £100K to protect a £10K asset.
If you have any questions or comments, please don’t hesitate to get in touch!
2018-12-06 00:00 +0000