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

Is Your Security Software Secure?

It seems like a silly question but how many companies take the extra steps to know that the millions of lines of code in their solutions don’t have any vulnerabilities? It’s easy to say your code is secure, it’s completely different to pay an accredited third party to review each and every line of code in your applications to ensure they’re free from vulnerabilities. It is with this in mind that Snare teamed with CA Veracode to review our Snare agent software and put them through the Veracode Verified program that would review the executable and application source, putting their own brand reputation behind their certainty. It is a lengthy process and the first to finish was our Snare Windows Agent with version 5.1 and Snare Agent Manager v1.1.0 that achieved Veracode VL4 security compliance. The VL4 status means that there were no Very high, High or Medium risk vulnerabilities in the applications as reviews by Veracode using the OWASP top 10 and SANS top 25 secure coding vulnerabilities. As part of the Verified program we have achieved Verified Standard.

What exactly goes into being Veracode VerAfied? It’s a back and forth between us and Veracode as they go through our application reviewing the code and check it against a policy using the Veracode OWASP top 10 and SANS top 25 known coding vulnerabilities to provide assurance that they did not contain coding vulnerabilities at the time of the scan. As part of the program we are required to perform rescans for every release and or every 6 months whichever occurs first to maintain the Verified Status. So its now built into our development and release process where the Windows Agent and Snare Agent Manager are constantly reviewed. Talk about an extra mile (or kilometer for those of you on the metric system).

Our competitors haven’t taken this extra step, and while we understand why, it was important to us that our best-selling products are built securely and are free from all known vulnerabilities. You can’t go a week anymore without major breaches making headlines and vulnerabilities can often be found in the most unassuming places. So, we went ahead and made sure that we are not only helping you secure your organization but we continually do so with the most secure solutions on the market.

Check out Veracode’s website to learn more about being Verified. 

Check out our page on Snare Agents to learn more about the world’s favorite logging tool.

/by

Why Your Own People Can Be Your Biggest Cyber Threat

Most of the time security professionals worry about zeros and ones – to simplify our entire industry somewhat. In essence, we’re trying to keeping our own assets protected and keeping outsiders, well, on the outside – and technology solutions, people and processes are obviously core to that.

However, there’s always one big grey area when it comes to putting effective cyber security protections into practice – our own people.

The reality is, if companies didn’t have people in them, they’d be a lot easier to secure. Unrealistic I know but it’s a fact. (And yes, in a previous blog I did also point out that not having the internet connected would also be quite good too).

No matter how secure your infrastructure, applications and devices, if a suitably-enabled staff member or contractor really wants to walk out the front door with private and confidential information, there’s little you can do to stop it from happening.

In addition, privileged users such as system and network administrators, database administrators, data owners, finance and HR staff can cause significant damage at an industrial scale if they maliciously attack systems or delete, change or leak sensitive information.

You’d hope it was detected very quickly, and perhaps DLP software will set off bells and sirens, and maybe even physical security will mitigate a malicious, physical attempt to steal information. But mostly – that information will just walk out the door.

So this is the interesting bit. In essence, after you have set access levels and rights correctly, you then have to trust that the people you also trust to serve customers and to behave within the cultural norms of common business practice have no intention of deliberately causing mayhem in your IT systems.

Of course with privacy and data protections laws and regulations tightening around the globe, that doesn’t seem like much of a security strategy. Naturally, every technology that should be deployed will be deployed to protect an organisation, relative to its business type and risk profile.

But what do you do about people!

It actually doesn’t come up as much as you’d think when you consider the discussions, news and general information coming across your desktop on a daily basis in relation to IT security. We see lots about devices and software that protects organisations or we hear a lot about the results of a breach from some malicious actors.

But the reality is that educating, supporting and communicating with staff about IT security (and all that entails) absolutely builds a more resilient and protected organisation.
There are a few things worth considering. These include:

  • How do we onboard new staff and contractors?
  • How do we reinforce various policies?
  • How do we oversee or educate employees that have been with the business for a longer period of time about issues like phishing attacks, shadow IT, securing sensitive information in emails, not plugging USB keys into devices on the network without security scanning (if it’s not already automatic) etc?
  • How do we ensure the business can still do business (and people don’t throw up their hands in frustration and look for a new job) but we still stay in business?
  • Implementing the relevant controls and tools that will help us verify the trust we have bestowed to some of our staff that have admin or access to privileged information.

Every company has their own approach, often built around international IT security standards.

However, dig below the surface and you can guarantee in all but perhaps military-grade sites, there can be big gaps between what should be happening and what is happening.
If it wasn’t true there wouldn’t be an entire dark web sector raking in millions of dollars per year from various nefarious activities.

So what’s the answer?

To some extent, (technology tools not withstanding), trust remains the watchword.

So trust comes from the overarching culture leaders create within a business.

Engaged, positive and tribe-oriented people value and protect their own. People who are aligned to their organisation’s success and take pride in their work, are less likely to deliberately steal or damage IT infrastructure and assets.

In most cases, accidents are captured by logging tools and security software and the like – and many people will put their hand up to admit they did something they shouldn’t have if it was an honest mistake. And of course, trust can also be verified to a reasonable extent with best-in-class logging tools.

What this means of course, is that for any CISO worried about security on a daily basis (and I’m pretty sure that’s at the top of the job description), they need to have one eye observing how their organisation looks after and treats people.

It may be that there’s not much we can do to influence a truly abysmal, pan-continental culture in a business, but we sure can be aware of what that means when it comes to setting a security posture and conducting internal audits. For example, it would also be prudent to review logs more assertively to verify staff activities and validate the trust levels that have been set.
It’s the difference between expecting and anticipating trouble.

/by