Monday, June 29, 2015

Electronically Aided Collisions and InfoSec

Like cruise control for your car, GPS assisted autopilots and the like for boats can help operators with mundane tasks like holding a course over a long stretch of water. Unlike driving though boating comes with additional challenges - keeping track of water depth, the impact of changing weather conditions, the fact that there generally aren't defined 'roads' or travel lanes, etc. The rise in adoption of electronic navigational devices has also seen a rise in what is being termed "Electronically Aided Collisions." These can range from a GPS device malfunction or signal interference which causes the boat to veer off course and run aground to a momentary (or longer term) judgement lapse where your attention is off where the boat is going and the general surroundings to the detriment of your boat - or worse - others.

While my sail boating father and I were talking about this and him sharing stories my mind starting drawing parallels to the InfoSec world. I've tried to boil these down really to two thoughts


Who are the next generation of security engineers?
We live in a world that is generating ridiculous amounts of machine data. We are compelled by audit and compliance regulations to configure our systems in a way that causes them to generate data at a very granular level, our operating environments are becoming more complex, and systems are becoming more interconnected (on prem, off prem, hybrid) which perhaps ironically can make understanding what is happening/has happened harder. While this isn't a bad thing it does require new approaches to capturing that data, parsing it, and making sense of it. There is certainly conversation where "doing more with less" in an environment that is generating exponentially 'more' could be had. That aside as we field the next generation of InfoSec professionals how do we train them to navigate the avalanche of data that necessitates the use of electronic tools in a way that let's them operate said tools and mentally reverse engineer what is happening in the environment that is generating the data in the first place?

To turn that last sentence around some - people have been 'doing security' for years but most have come from various IT backgrounds and have fallen into security as it were. They are able to draw from their technical experience as they pursue a career track that has a security bent. It is a relatively new thing for the need to be understood and InfoSec treated as a profession, at scale, beyond simply something someone in the IT shop does. This has led and is leading to the development of Information Security degree tracks in higher ed and other security training programs in order to fill job position gaps. All good things(!) - but how do we develop security engineers (or an engineer mindset) based on how computing systems work and pragmatic experience instead of people who can just pass security tests?

Tool augmented security vs tool driven security vs lights out security
Adding electronic tools to our utility belts is a good thing. Automation in general is a good thing! Both CAN allow someone or a team to do more than they otherwise could do manually be that triaging a system or interrogating gigabytes or terabytes of information for useful nuggets and taking action. Getting to the point where all of that happens automagically in a holistic way across a complex environment and in a way that ignores the human element though...? Similar to the GPS driven autopilot that works 99% of the time - except for when there is a few minute hiccup and you run aground - what happens when there is a change to the environment and your automated actions cause an issue. Anyone running a fully automated IPS? An over-reliance on security devices to take automated actions can and will have an impact at some point which might end up impacting the security program negatively for a longer period than the actual outage.

In summary I wonder at the convergence of both issues. We end up with what I might call Electronically Aided Blindspots. These blindspots can occur on two fronts. The first is missing segments of data flowing into your electronic tools that you either aren't aware of because of environmental complexities or because the data isn't available (ie many cloud vendors). The second is reliance on said tools to the point where you trust them more than your eyes/experience/common sense. The classic case is how many times have you had system admins/system owners say even though a system exhibited anomalies it can't be infected by malware or otherwise pwned because the local AV software isn't triggering on anything? Of course the worse scenario on this front is when your security tool operator lacks the ability to interpret the data the thing IS generating and is unable to make a decision or tune the thing.

So do you have any EABs and which is overshadowing your visibility - the data (not) flowing into your security devices, an over reliance on your tools, or the tool operators?

No comments:

Post a Comment