Here’s the thing. Every IT shop is different and IT infrastructure is different.

There is no homogeneity in the organization, its infrastructure, nor tools deployed.

But IT shops are all quite similar in one regard. Most that are bound by compliance (PCI DSS, COBIT, ISO/IEC 27001 and 27002, NIST Information Security Handbook, ITIL - pick your framework poison) take a questionnaire approach to those things that they know they will be audited against.

This is a decision taken out of necessity for the most part.

IT staff are overworked and overburdened. They spend their days fighting and putting out fires across the business. So they are forced to take a checklist approach to compliance in order to stay afloat, keep their sanity and live to fight another day.

Need a VPN?  Check.

Got a firewall check check.

Disaster recovery plan? Yep, cross it off the list and move on.

This way, when an auditor arrives and looks for proof of controls in place, your IT guys can confidently look them in the eye and produce evidence that they have satisfied all the necessary checklist items required to satisfy compliance.

But there’s a dirty little secret associated with this approach. Compliance does not mean you have implemented a highly secure, rock-solid infrastructure. Compliance will not protect the business from intrusion and risk.

Compliance is the floor, not the ceiling. It is the bare minimum standard of protection.

Those CIOs and their teams who believe they have done their job by completing a checklist do so at their, and the business's peril.

Because within each of those checklist items -- let’s use a firewall as an example -- there are best practices in the way that technology is implemented and configured and connected to other infrastructure components. And within those configurations lurk some very insecure items that are rarely addressed by IT programs. If one really has the ambition to go to the Nth degree in ensuring a high degree of compliance for your IT organization and confirm your implementation of that technology hasn’t violated any standard, you can usually find these best practices buried in vendor documentation. Best practices may also be outlined at the Center for Internet Security or within the US Department of Defence’s Security Technical Implementation Guides (STIGs).  

Show of hands now -- who has the time to go looking?  Anyone?

Let me give you an example of one situation that often comes up in client conversations. Companies often have servers located on the DMZ, an area that is publicly accessible to the outside world. These servers are hosted internally, and are supposed to be cut off from the rest of the network. Companies don’t think much about it. But looking deeper, these server types are frequently very outdated. They can have multiple known vulnerabilities that should be updated. So while in theory, such a server is cut off from the rest of the network, it provides an entry point that a clever intruder can use to create a pathway through it to get straight into the internal network. Or at the very least, install crypto mining on the network.

Stories like this one are common among the IT shops I visit and across all industries from manufacturing, to financial services, to retail and beyond. And it brings me to the heart of the issue and the most important takeaway for those reading this blog.

Do you know what you have in your IT infrastructure?

What’s your inventory?  What’s installed? Do you know?  Whose responsibility on your team is it to keep track of what's in your IT infrastructure and how it got there?  

It’s not necessary to know what is installed on each of your employee’s devices (although that’s a pretty great thing to have) but at a minimum, you should have a documented inventory of things directly in the purview of your IT infrastructure responsibility.

Next, do you know what’s installed where and how it is configured and is that configuration following a certain benchmark?  Is it up to date? Do you know who was responsible for installing that technology?  Do you know the risks associated with this item?  Do you know what kind of data is stored on it?  Do you have duplicate technologies or technologies that you are paying for but not using?   What happens if ‘Fred,’ your IT guy, (and the only one who really knows that server) wins the lottery and retires?  Can someone step into Fred’s shoes, update technology or change something in its configuration and know with a high degree of confidence that it will not break something and take the server (and maybe the business) down?  

If we take a pure checklist approach to compliance, we might document that computer A is marked as containing sensitive information. But the compliance checklist does not ask the questions I’ve outlined above. Not by a long shot.

And then there are those emerging technologies such as Kafka, Druid and Spark. They are ubiquitously used but currently have no associated third partner benchmark. In these circumstances, IT shops are at the mercy of vendor documentation with respect to the proper configuration. It might have been installed as a temporary solution, but it’s doing something and ends up getting moved into production. And most of those IT shops are just happy that it's running. They don’t stop to wonder what risks these bleeding edge technologies might be creating.

Having a current accurate inventory of your infrastructure is vitally important. But it is not an easy thing to build. And it’s a virtually impossible task to do manually.

Just think of a large conglomerate that has done a bunch of M&As with many heterogeneous environments coming together. It’s complicated and it's messy. And because these environments are for the most part a black box to the organization, it is probably getting in the way of that business doing cool new stuff.

Failure to predict the future leads you to disaster. Forward-thinking, progressive organizations understand this deeply. But they are few and far between. Rare is a company like Netflix, which has deployed the Netflix Chaos Monkey ​​responsible for randomly terminating instances in production to ensure that Netflix engineers implement their services to be resilient to instance failures. It’s an extreme interpretation of vigilance and diligence.

But then again, when was the last time your Netflix went down?

Did you know there is a tool you can use that will continuously scan your entire infrastructure documenting what’s in inventory, how it's configured and all the details in between?  Contact us today at CoGuard to see it in action and get an instant free scan and report.