The InfoSec Student Part 3: A Focus on the Fundamentals

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). 
 

Focus on Preparation, Awareness, and Response   

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. 
 

PREPARATION: PEOPLE, PROCESS, TECHNOLOGY 

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:  

• Provide training on the infrastructure, the computing environment, and the applications within. Your InfoSec team cannot protect an environment that they don’t understand. 
• Ensure that your personnel are trained on the tools you implement, and specifically on telemetry relevant to the technology that exists within the protected environment. 
• Implement a Quiz system from 1 and 2, and then use the results as key performance indicators (KPI).  
• Include 1 and 2 as part of your continuous monitoring program.  

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: 

• Steps taken to implement tools. 
• Troubleshooting steps taken. 
• Tasks and requests fulfilled in the process of executing InfoSec duties.  
   

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: 

• Don’t implement new tools until you have achieved operational efficacy in the ones you already have. 
• Avoid functional redundancy by maintaining a crosswalk of requirements to tool functions, to the tools that you use. 
• Pro Tip: Include governance controls in your crosswalk to make audit season a breeze for your team.  

AWARENESS: STEP 1 IN THE TAO OF TELEMETRY 

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: 

• Maintain an inventory of systems and applications within the environment.  
• Ensure that both systems and applications are feeding event logs to a separate, protected environment.  
• Implement and report a monthly (at minimum) KPI comparing your inventory against log sources.  
   

RESPONSE: IT’S ALL IN THE REFLEXES 

“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: 

• Strategic, Tactical, and Operational components. 
• Proactive as well as reactive guidance. 
• A process that describes and documents steps for preparation, identification, containment, eradication, reporting, and lessons learned.  

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.”