Home » Issues
Category Archives: Issues
Three Common Technical Failings
A regular part of my work is to undertake technical audits of IT systems, and report on my findings.
This is different to a Penetration Test in that an audit confirms the general health of a system rather than attempting to break into it. It is similar to the difference between the local Crime Prevention Officer having a look at your house and giving advice to help you remove weaknesses, and a burglar casing the joint. There are three things that are seen in almost every audit: I could almost write part of the report in advance.
Patching is not maintained.
Implementing the vendor’s patches remains the best way of reducing the number of security issues within a system. This should be done regularly and against a defined policy.
The policy is important, as it defines the maximum window of opportunity that an organisation is willing to tolerate for their systems to be vulnerable. For systems where the protection of the information is critical, a policy of patch production immediately may be appropriate, and the risk of disruption is acceptable. This is often known as “Patch and be Damned”.
For less critical systems, then you can test the patches before a large monthly patch deployment.
Antivirus is not up to date.
Antivirus systems, despite their limitations, remain the last line of defence against malware. They are at their most effective when they are able to deal with new attacks, and to do this they must have the latest signature files and the latest versions of the detection engine.
As with the patching of software, antivirus software (properly called malware detection software) should be kept up to date in accordance with policy.
Antivirus is not fool proof, and should not be the only form of defence, but if you’ve got it, then make sure it is effective.
It is reasonable to have one policy document that covers patching and antivirus.
Firewalls are open.
The purpose of a firewall is to limit the connections that can be made through it. Restricting which devices can talk directly to others, and which protocols or ports they can use will hamper the spread of any attack. It must only allow connections that are required for the solution to work and no more. Any additional rules, however convenient they may be, reduces its effectiveness.
And if I see a bunch of rules followed with “default = allow all” I will comment on it.
Take note and consider this a free bit of advice. Following it makes you safer (and adds variety to my work).
The President’s Phone
It appears that President Trump remains committed to his elderly Android phone. This has caused a flurry of speculation on the risks of doing so. There was a similar debate about President Obama retaining his Blackberry when he took office.
This was a subject I discussed with the US Secret Service during one Obama’s State Visits; and sensibly there are limits on what can be said publicly, so I will avoid going into specifics.
So, what are the Risks here?
- Access to sensitive information on an unencrypted device? Physical access to the device allowing access to data at rest, or account credentials – usernames and passwords. Unlikely, the device is in the jacket pocket of the US President – there are adequate physical controls. This was viewed as adequately managed.
- Remote access to data? This is a more significant risk. If it is a stock devices, running an old version of Android there are unpatched vulnerabilities that allow an attacker to obtain information from the device. At Rest storage encryption doesn’t help here. This remains a risk, and is a good reason for retiring the device. Especially given that obtaining credentials for e-mail and Twitter accounts could be a extremely usedful for an attacker. It is quite possible that this would both as a result of a targeted attack on President Trump or an untargeted attack that just sweeps up all credentials from any device they can find.
- Evesdropping? Again these are attacks against vulnerable, unpatched, devices, and they are available to foreign intelligence services. These attacks enable the device to become a sophisticated bug in any room. Such an attack would be of great interest to foreign governments in giving access to sensitive and non-public discussions. This is going to be a highly targeted attack by highly capable attackers and a significant security threat.
- Location tracking. A mobile phone of any nature has to talk to a network to operate, and that, as well as any compromise of a smartphone to get it to report location. This can be used to understand where it is at any time, and any pattern of movement. It is extremely valuable information that can support both a direct attack on an individual, and to obtain information on who they meet and regular patterns of behaviour. Location can leak by many paths, data in images, social media posts, and is frequently overlooked. This location tracking threat is a critical concern to the physical protection of a VIP.
So, if your Risk Assessment indicates risks that you are unable to accept as part of your business, what controls can be used?
Require a device with patched software and applications that are still under support. Your employee may like their old Galaxy S3, but is their using is a risk to your business? It is at this point that BYOD meets security and should be addressed in the mobile working policy (“BYOD, but not any device”) – unless you are confident in securing and supporting every mobile phone made in the last fifteen years.
The use of an always on VPN, bringing all data traffic back to a point where it can be monitored for abnormal or unusual behaviour. Not all data can be monitored, unless you wish to compromise TLS connections, and users may (quite rightly) object to that on devices they also conduct personal business on. Monitoring, and acting on, unusual connections and activities is normally sufficient.
Periodic audit of the device to identify any unusual or unauthorised software or apps. Either using software continually running on the device, or by periodically inspecting the device with tools.
Controls over where devices are not allowed. If there are particularly sensitive areas in a business, or sensitive conversations, then ban devices. Provide small lockers to allow users to store them outside of the area.
Advice, guidance and training for users. And record when it has been delivered.
Remote disabling or wiping of the device.
Remote application execution: VDI for mobiles, or deliver all information through TLS browser sessions without requiring apps and data storage on the device.
The only control normally beyond the reach of a business is to use a private, closed, network with technologies to prevent RF or network based user tracking. But you would only use that in the most critical of cases…
Fake News
“Fake News”, misinformation, has been in the News recently.
2016 was the year when deliberately misleading “news” stories, used to manipulate public opinion and to directly influence events, really came to the fore. So, what has this to do with businesses, and why, as an Information Security Specialist am I interested in it?
It can be a significant threat to a business – either directly, where fake news has been made to damage a company or influence it’s share price, or as a result of a different attack.
This relates to the circulation of “incorrect information” that is a threat to the business – analogous to the use of incorrect information within the business. The key difference is that the incorrect information is not held and managed by the business.
So, how do you mitigate the risk?
- Be able to respond quickly to fake news:
Have a Response Plan, know in advance who will be involved in the response, and how you will co-ordinate and manage this. - A credible and engaging reply to the story.
This will depend on the nature of the threat facing you. - You also want to ensure that any insurance you have covers such events to mitigate any significant financial loss or damage to the business.
A major problem in addressing such a fake news story is that responding and not responding may both cause an escalation by the attacker:
- Well, it must be true because they obviously can’t correct it or deny it. Or,
- Well, they would deny it wouldn’t they.
This means that you will need to have expertise available to support you in minimising the damage.
Cyber Insurance
There are three ways of managing IT security risks in a Risk Treatment Plan.
- Accept the Risk – a positive decision to accept a risk to the business as being something you are comfortable with.
- Mitigate the Risk – put a control in place to reduce the risk.
- Transfer the Risk – move the cost of the event happening to someone else.
Transferring the Risk is commonly done by Insurance, although there are other methods of Risk Transfer.
Cyber Liability Insurance Cover (CLIC) is often overlooked as an option to help a company survive a critical loss of data or a major security incident. The market and take-up of such insurance is variable. In the US, some form of CLIC is often a regulatory requirement, so take up is high. However in the UK where there is no requirement for a business to be able to survive such an event take up is very low (approximately 1% of UK companies have some form of CLIC).
While some form of Insurance is invaluable to aid a business during a disaster, be it flooding, the loss of a critical member of staff, or a massive business crippling data loss; the devil is, as always in the detail.
I have worked with several large organisations in reviewing their compliance with the expectations of their insurers and have two key lessons:
- The Cyber Insurance Market is relatively recent and has little historical record to generate risk profiles against, additionally, the market is relatively small at the moment giving a low spread for insurers to work against. This has a direct impact on Premiums.
- The Cyber Insurance Policies place obligations on the policy holder to have a good level of security management and protections in place. In many places, this obligation is not complied with – leading to the possible non-payout of the insurance contract.
Insurance services are adapting to this with schemes to reduce Insurance Premiums based on the results of security audits – both to inform the Insurer of the risks they are running and to give the policy holder assurance of the validity of the policy.
OpenSSL End of Life
One of the most commonly used pieces of security software is the OpenSSL cryptograhic library. It is used in almost all Linux based systems and it is packaged in a significant number of Windows applications and, of course, used in the Internet of Things devices, as well as various security appliances and VPN firewalls.
OpenSSL is an Open Source Project, one which has – through good reasons – now adopted a formal release model for their various versions.
Support for version 1.0.0 and earlier has already ended. OpenSSL support for version 1.0.1 ends on the 31st December 2016 – the end of this year.
Why is this important?
The OpenSSL library manages the creation and operation of secure network connections.
- It manages the HTTPS bit for most secure web browsing.
- It manages the connections of secure VPNs connecting users into corporate networks.
- It manages the security for administrators remotely logging into linux servers.
- It manages the hashing of passwords.
There is almost nothing in the security space that OpenSSL does not impact. It is a large and complex piece of software, and has been the subject of some of the most highly publicised and critical IT security issues, such as Heartbleed, which have led to a lot of developer effort being expended on it across all of the versions. [Hence the new support plan]
As OpenSSL is used for so many functions, any upgrade has to be taken with extreme caution. Internal testing by Trusted Management indicates that a version upgrade frequently breaks dependencies requiring additional effort to implement workarounds or alternative systems.
- The current major Linux Distributions, with the exception of the latest Ubuntu release, use OpenSSL Version 1.0.1 and thus will require patching.
For supported distribution versions it is expected, though not confirmed, that these will be available through the repositories. - Applications on Windows platforms that use the OpenSSL library will need patching.
These should become available from the software vendor. - Devices, such as Firewalls and VPN terminators, will need patching.
These should become available from the vendors for supported devices. - Internet of Things devices will become increasingly vulnerable if they are not patched.
Failing to patch OpenSSL will leave systems exposed to any vulnerabilities (such as a new Heartbleed) in those systems.
Unpatched systems will also be a major non-compliance on any regulatory or contractually required audits such as PCI-DSS.
