Thoughts on Information Security by Neil Quiogue

What Security Framework To Use?

Starting a security programme is a daunting task depending on the size of the organisation.  Thus, organisations look at existing security frameworks to help provide the structure for that programme.

In the industry, there are 3 of the most well-known and implemented frameworks: ISO 27001/27001, NIST Cybersecurity Framework (CSF), and the CIS Critical Security Controls (CSC).  I know there are others who used COBIT and ISA 62443 (also known as ISA99) but they are not as widespread from my experience due to either scope (ISA) or complexity (COBIT).

From a complexity perspective, here are a few high level statistics:

  • CIS CSC (2017) has 20 security controls.
  • NIST CSF (2014) has 22 categories and 98 sub categories.
  • ISO 27001/27002 (2013) has 114 controls.

So does that mean that ISO is better because it has more controls?  Not necessarily as there have been a number of mappings made between frameworks and there are instances wherein a control is in NIST CSF but not in ISO 27001/27002 and vice versa.

Having gone through these frameworks (and knowing that no organisation is alike so your traction may vary), the NIST CSF offers the best of both worlds in terms of comprehensiveness as well as simplicity.  Comprehensiveness in that the high level functions Identify, Protect, Detect, Respond and Recover cover the key areas of an information security programme.  Simplicity in that each of the categories and subcategories are easily understood.

However, what it doesn’t provide is on the prioritisation.  When you identify a number of gaps in your security programme (against your chosen framework), you need to prioritise as you will not have enough resources to execute on it and the organisation may not have enough change tolerance for the programme to be successful.

For this, the CIS CSC will help as it is based on a practitioner’s experience on which controls actually work.  It was written in such a way that it is prioritised.  However, I would exercise caution on using its prioritisation as gospel as there are a few priorities which I don’t agree on its placement.  For example, I would recommend having an Incident Response Plan and Process (CSC 19) earlier than sooner as you will be faced with security incidents (with varying magnitude).  It does not have to be perfect in the beginning but you should have one especially on the different roles and responsibilities and when you should be communicating.

And the CIS CSC tends to focus on the technical security controls so before you even utilise it, you need to have the ‘Identify’ part in the NIST CSF done first (related to that are the sections on Information Security Policies and Organisation of Information Security in ISO 27002).  This is to help provide the foundation for your security programme wherein you identify your business environment (and what’s important to the business), identify the key risks and assets, and identify the governance needed to inform your strategy.

I hope that helps provide some food for thought.

References:

  • (2013) ‘ISO/IEC 27001:2013 – Information Technology – Security Techniques – Information Security Management Systems – Requirements’, ISO/IEC.
  • (2014) ‘Framework for Improving Critical Infrastructure Cybersecurity’, National Institute of Standards and Technology [Online]. Available at https://www.nist.gov/sites/default/files/documents/cyberframework/cybersecurity-framework-021214.pdf (Accessed 4 September 2017).
  • https://www.cisecurity.org/controls/ (2017) CIS Controls [Online]. (Accessed 4 September 2017).

Organisations Still Need to Improve on Security Hygiene

I am back!

Revisiting the recent cases of ransomware that affected a number of organisations around the world, they show that organisations still have room to improve on the security hygiene front.  When I say security hygiene, these can be aligned to the Critical Security Controls (CSC) that are being promoted by the Center for Internet Security (CIS) [https://www.cisecurity.org/controls/].

Just going to the inventory side of things, does your organisation have a complete inventory of all assets (both devices and software)?  It goes back to you cannot protect what you don’t know.  In smaller organisations, this is easier to manage as you have a smaller population of users and devices.  In bigger organisations, it can become an issue.  These organisations will normally have a Configuration Management Database (CMDB) that will house all known assets.  However, if your organisation does not have a central procurement function (where all procurement of assets need to go through) then you will have an issue.   People will get their own devices and even connect to your network.  Or they will procure cloud-based services if their IT services functions are not able to address their business needs.  I will go through some thoughts on this at a later article.

Assuming you have a comprehensive inventory of devices and software, do they have secure configurations?  There are a number of organisations that have published benchmarks or implementation guides ranging from the CIS to the US Defense Information Systems Agency (DISA).  This can be contentious as some teams will either say they don’t have the time to look at all the configurations or that it will break things.  There are tools out there (like the one from CIS) that allows you implement those benchmarks and potentially tweak it to match what works in your organisation.  The CIS has a Configuration Assessment Tool (CIS-CAT) to help identify gaps in your current configuration standard.

In the case of CIS, I would recommend implementing at least the Level 1 recommendations.  If you have some legacy systems (e.g., Windows 2000/2003), then some of the recommendations in Level 1 may break certain functionality so it is important you review the impact.

However, in the case of the recent ransomware attacks, one of the Level 2 recommendations on “Interactive logon: Number of previous logons to cache (in case domain controller is not available” is recommended to be set to 4 or lower.  Normally this is set by default to 10.  The reason this is important is that in the event that the ransomware is able to get the passwords, the number of accounts that could be impacted is minimised.

The next security hygiene is in continuous vulnerability assessment and remediation.  A number of organisations need to address their lifecycle management more seriously.  EternalBlue was released by ShadowBrokers in mid-April 2017 which exploited vulnerabilities patched in MS17-010 (which was released back in March 2017).  WannaCry was released in May 2017 and affected a large number of organisations.  When NotPetya appeared towards the end of June 2017, there were still a number of organisations affected (admittedly, NotPetya had other methods of spreading).  What the recent ransomware attacks have shown is that patching vulnerabilities need to be more frequent than what organisations have done so far.  One cannot make an excuse that it takes a long time to do the testing.  If it takes too long then one should look at the processes used for testing as there may be an area of improvement there (e.g., more automation).  And note that it only takes a few vulnerable systems to be compromised for it to spread enterprise wide especially with ransomware utilising a number of methods to compromise an environment (e.g., key logging, acquiring passwords in memory, etc.).

The last point is on controlling administrative privileges.  Users should not do their day-to-day computing tasks with administrative privileges.  The reason is that if they access a malicious site or open a malicious file, malicious software will run in administrative mode and infect the whole system or worse, other systems where that user exists and have the same administrative privileges.  If a user is only operating as a standard user with minimal privileges, then the attack blast is going to be limited (and will not likely infect the system files).  I say unlikely since if the malware exploits a vulnerability that still exists in the system then it could still gain administrative privileges (and this is why addressing vulnerabilities rank higher than controlling administrative privileges).

You may have wondered why I haven’t covered Malware Defences in this entry.  It is considered part of security hygiene but is not ranked higher than Inventory, Secure Configuration, Continuous Vulnerability Assessment and Remediation and Controlled Admin Privileges.  The reason is that malware exploits vulnerabilities and insecure configuration.  And the recent ransomware attacks were not detected by traditional signature-based solutions (as they weren’t detected before) and they spread quickly (with all the automation that malware nowadays have in its arsenal).  However, I will tackle this topic in the next blog entry.

Keep safe everyone.

References: