Daniel Deter is the Manager of Information Security at Green House Data. Follow him on LinkedIn.
In InfoSec we continually encounter the unknown, the unfamiliar. Technology marches ever forward, application design matures, bells and whistles chime and toot. This commonly results in the InfoSec professional needing to responsibly secure technology that they don’t holistically understand. Attackers know this, for it is within those gaps in understanding that malicious activity may most readily occur and may do so without notice.
A common InfoSec response to the unfamiliar is to attempt to cover all potential angles of attack, regardless of whether they are pertinent to the technology. This is done in order to ensure that we meet both risk and governance management goals. The result of this approach is rarely better security. Rather, it typically results in unnecessarily complicated security control implementations that are neither functional (e.g., they don’t do what we want/expect them to do) nor operational (e.g., our personnel can’t adequately manage them).
An effective InfoSec program isn’t about flash and pizazz. It’s not about high-priced tools, or the latest buzz term that the guy on the phone just assured you is required to protect your computing environment from the barbarians at the gate. Effective information security is about focusing on the fundamentals of risk management: preparation, awareness, and response.
Consistent with Goldratt's theory of constraints, any InfoSec technology or controls implemented prior to adressing the fundamentals will not improve the state of risk management within your organization and computing environment. Furthermore, unnecessarily complicated security control implementations are themselves a constraint.
As an InfoSec manager supporting governance, cloud technology, and managed services, I’ve quite often found myself faced with the unfamiliar. I’ve also found myself sitting on (or directly responsible for) over-complicated control implementations. I developed a mantra: under-comprehension drives over-complication. I would then ask myself, and my team, if we properly understood the tech/topic, and whether we were over-complicating our response.
How do we avoid over-complication in our security controls? We focus on the fundamentals: Preparation, Awareness, Response.
People are always a work in progress, and that’s a natural and healthy state.
The foundation of successful people in InfoSec is the establishment of a framework within which they can grow and be successful. In order of importance:
Processes help close knowledge and operational efficacy gaps by providing consistency in your response to an event.
You can’t reasonably proactively write all your Standard Operating Procedure (SOP); instead focus on developing a culture that builds SOP as part of standard operations. When completing a task ask, “Will this need to be done again?” If the answer is “Yes” (it will be), then write an SOP for the next person who encounters the task. Do this for:
Technology is the vehicle through which an InfoSec team interacts with security-relevant data.
There is a lot to be discussed about technology that benefits risk management, and that’s not the function of this blog. Rather, I’d like to offer a few items of guidance:
Awareness is the first step in anomaly detection. Anomalies represent the events occurring within the protected environment that may represent a security incident. The foundation of awareness is not analysis of your data, rather it’s the collection of the data itself. To obtain the foundation of awareness:
“It's all in the reflexes.”
- Jack Burton
Designing an environment to be impossible to breach is designing for failure. Instead, design for practical defense.
If you’ve followed the previous guidance from the InfoSec Student Part 1 and Part 2, then you’ve established or are in process of establishing a foundation built on personnel training, practical processes, and awareness of events occurring within the computing environment. This results in functional controls that are more likely to result in identification of malicious activity. And that supports response, that is, your incident response capability.
This capability should include a formal incident response plan, which includes:
Infosec Student: “But Deter, that’s a lot of potential complexity. How do I build a functional incident response plan?”
Deter: “That’s easy. Stay tuned for InfoSec Student Part 4: Incident Response Plan, where I’ll give you an actual, functional incident response plan.”