The Security of Everything

Unless you’ve been out of contact with civilisation for the last few years, you’ll know about the Internet of Things (IoT).

Just to catch you up, it’s the advent of a myriad of devices which are not only connected to the internet but also, in many cases, generate data.

What sort of devices? Think about any smart device, or any monitored device or any internet-aware device. It could be any or all of the following, which can be found in most organisations:

  • vending machines that notify the operator when stock is low, cash boxes are full, or change is required
  • remotely-monitored exit signs that light the way to your fire exits.
  • IP phone systems
  • multifunction printers (a recent exploit has been uncovered which allows bad actors onto enterprise networks via unsecured fax lines connected to certain multifunction printers)
  • smart whiteboards and projectors
  • security swipe card systems
  • elevator and other building management and monitoring systems
  • unmanaged end user devices connected over the enterprise Wi-Fi network (a reasonably recent example was an internet-connected thermometer in a fish tank in a casino’s lobby, which let hackers access the company network and steal high roller data. I assume the fish denied everything. Or maybe they were just being koi. (Sorry.))
  • CCTV systems which may connect to third-party security providers
  • smart TVs, fridges and other appliances in the corporate kitchen, even though the ‘smart’ component often isn’t even used in a business kitchen setting.

And, as we know, where there’s an internet connection, there’s a threat vector.

The problem with IoT is the unstructured and unmanaged nature of these connected devices. In many cases, the manufacturers of these more general devices are mostly focused on the specific functionality of their appliance and may not even consider wider enterprise security ramifications.

Internet connections for many devices may be active by default, and often not able to be patched or managed as they are hard-soldered onto circuit boards. And, in some cases, you may not even know that a device is internet-aware and could be acting as a gateway onto your corporate network.

It’s fair to say that, for many organisations, worrying about being hacked via the smart TV or the Wi-Fi sound bar in the company boardroom is not top of mind.

So what’s the answer?

First, if you haven’t thought about it already, be aware that this is a threat vector. It’s one that only deliberate attackers would attempt to use, which makes any kind of breach probably quite serious.

Consider that it takes serious and direct effort to try to break into an enterprise network via a smart fridge or the CCTV system.

Second, identify and isolate these devices with network segmentation. Use any of the available technology tools to find devices that transmit or attempt to connect to the network or the internet, and determine the best course of action from there. If they need to remain connected (or you can’t turn the connectivity off) then make sure they can only access quarantined parts of the network. If they’re wired devices, ensure patch panels are wired correctly and network leads aren’t accidently plugged into a secured or other production networks.

If devices transmit and receive wirelessly, ensure they can only communicate over guest or utility-rated network connections.

Third, (or maybe first depending on your approach) ensure your IT security management procedures and policies address IoT. Develop protocols and procedures around the receipt, activation, screening, and management of internet-enabled devices which are consistent with adding any other network-enabled devices. Make sure facility managers know about these protocols and procedures, as building management systems are increasingly the focus of external attacks.

Fourth, train people and ask them to acknowledge the policies you have in place. It’s important that staff, contractors, and visitors understand the implications of connecting any kind of device to any active network in the organisation and don’t do it without -permission.

Last, put technology in place to monitor, log, and notify you if there is suspicious activity on your networks. Many organisations are doing this anyway as part and parcel of managing IT security, but this is becoming more important in an IoT world. Logging tools and threat intelligence solutions are the cornerstone here.

While IoT offers many benefits when it comes to productivity, convenience, cost savings, and many more areas, it does open a whole new front when it comes to fighting cyberattacks and protecting organisational assets.

/by

Incident Management from a CISO’s Perspective

Incident management isn’t too far from most CISOs’ minds in any given day.

If you read the news, any news, you’d be forgiven for thinking incident equates to some kind of catastrophic breach. Well, that is an incident of course, but the reality is that in the IT management world, an incident is any kind of unplanned activity as it relates to IT infrastructure.

It can cover the newsworthy major security breaches, but more often, incidents are equipment failures, corrupted applications, incomplete backups and damaged end user devices. They can also be unauthorised data leaks, theft of equipment, computer viruses, breaches of internet usage policy or the intentional destruction or theft of data.

It’s a bit of a laundry list and you can see why policies and security management frameworks have become critical for dealing with them. Not all incidents are of equal importance to any one organisation and the process for dealing with them will always vary.

The over-arching standard most organisations work to is ISO27001/2. Actually, it’s a whole series of standards under the ISO27000 umbrella with some 45 documents going from high level to very detailed areas – but if you Google it you’ll get the gist.

Give or take a few sub points, the IT security management standard (ITSM) lays out a framework to assess an incident (What sort of incident is it? How serious is it?), respond to it, eradicate it, restore whatever function was disrupted by the incident and finally, review what happened and how the incident was dealt with to see if there are learnings and improvements to be made.

There are additional standards and regulations that different organisations will lay on top of this more general ITSM approach. For example, if you need to comply with PCI DSS regulation because you access, store, transmit or manage card holder data then you need to run at least an annual incident test to see how well your systems, policies and processes stand up in the case of a breach.

Likewise, banks and other large financial institutions can be required by regulators to prove their disaster recovery systems will stand up in the event of primary site failure.

An interesting side-note here. Policies also form part of an ITSM system. These are those extra documents you sign when you join an organisation, and cover areas like agreeing that you won’t use company-owned equipment to host Call of Duty games, or you won’t email data to a personal account, or comment about confidential company information on social media. Breaches of policy are also incidents, and the consequences are usually laid out in the agreements you sign on joining a firm.

Logging is good

Logging tools have an important role to play in not only flagging incidents as they happen, but also in providing an audit trail of events leading up to the incident. That might be a technical malfunction or a deliberate attempt to hack into the corporate network.

Logging tools like the ones we offer at Snare have a small footprint, are extremely durable and can be dialled in to the specific characteristics of different kinds of networks and end user activities. If you don’t use logging across your system now, it’s definitely worth considering and will improve your ITSM significantly.

Managed Security Service Partners – where black and white turns grey

Last but not least, it’s worth quickly touching on the additional complexity that comes when your organisation signs up with a managed security service provider (MSSP).

It seems kind of obvious, but make sure you really have a handle on exactly where your responsibilities end and the MSSP’s begin. Often MSSPs will be tasked on edge security, but core security is up to you. Or they’re focused on enterprise systems, but not end user devices.

Make sure you map out exactly who is responsible for what and build detailed service level agreements to suit. It’s an increasingly common story (more so in mid-to-small sized firms) that a lack of clarity about responsibilities between parties led to significant, expensive and sometimes company-ending incidents. Don’t assume the MSSP has got you covered unless it’s in writing.

If you want to know more about our logging tools you can find more information at https://www.snaresolutions.com/resources/ and you can find some great resources on ISO27001 here

https://www.snaresolutions.com/wp-content/uploads/2018/05/Snare-for-ISO-27001.pdf.

For specific areas on incident management NIST publish a great guide, it’s 70 pages of goodness and not a difficult read and also contains some other links to good references for any security teams.

https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-61r2.pdf

/by