Over the lifecycle of a cybersecurity incident, at which point is it most* easily disrupted and prevented?
Two competing strategies are:
1. Focus most of your efforts on initial penetration prevention that have the potential to be the most damaging to your environment, e.g., patch management, social engineering training, etc.
2. Focus most of your efforts further within your environment to locate Defender or Blue Team decision points that constrain adversaries into bottle necks, contain lateral movement, for easier disruption.
Is there a better strategy than these two?
*One strategy is not saying to completely ignore the other, key word is "Most".
@BeadsSome great insights you are bringing to the conversation here. What are your experiences of taking a more proactive approach in terms of actually using Orchestration and Automation and bringing this to the table.
Thus mitigating and reducing the impact of a detected intrusion attempt, using a SOAR:
the approach will change based on where you are at in the incident.
I took the question as meaning the entire life cycle, not that it had already occurred.
Prevention is best but not a 100% guarantee. You need to know how to respond at each step.
@GerrySAnd yet Federal government is stating we should change our stance and be more proactive rather than reactive.
Regards
Caute_Cautim
My background is firmly in training new privates over and over for years in both active duty, reserves and National Guard. Toughest thing to deal with is a team be they Forward Observers (artillery grunts who direct fire) or security practitioners is training and instilling a sense of ownership for the team as a whole.
You need to reinforce basics till everyone understands every aspect of the job then move training forward in increasing increments. I used to keep a notebook of quick task trainings in my pocket to keep drilling basics. Took a couple of minutes to do and everyone got used to the routine and helps build comradery. I see the same problems in this field. Always training a new person expecting them to know everything out of the box. It doesn't work that way. Teams are built through trust not assumptions. Otherwise, your going to have one or two outstanding specialists on your team, while the rest feel a bit outside of the team. Sound familiar? It should as it happens in InfoSec just as regularly as it does with a front line unit.
What does this mean to a security team? Everything. Whether you wish to stop threats before they take hold or simply react to the problem it still takes a coordinated team not a single ubermensch who will either outgrow the position or simply move on because they are saddled with doing too much and not able to rely on the overall team. We have the technologies and abilities to quickly identify and kill many of these threats but we lack the internal coordination to do so. Again, training and cross training is a group effort not just an individual effort. As a Senior Director working with many teams across the globe I see this both in my organization and client sides. Wonder why we have such turn over?
This is a two pronged approach. First identify your weaknesses from a historical viewpoint. Then your current asset threats, train your team to recognize what the machines are telling you and stop playing 'whack-a-mole' reacting after the fact. Your team will know what your most critical problems are - ask them! Again, teamwork not a collection of egos riding roughshod over the organization. We did that back in the office of 'No!' days and it didn't work. I see the 'whack-a-mole' mentality almost daily and its counter productive.
Training your people and sharing knowledge should be slightly competitive to do and rewarded not siloed so everyone has the opportunity to grow. Twice weekly team meetings organized in the Agile or Scrum formats work well. Same with getting all your architects together twice a week and 'food fighting' your way through design problems. OK I am being kind about the food fight example. Seasoned architects tend to go straight to blood letting in the consulting world but its effective. 😁 Attending scrum and developer meetings is not out of my realm to attend as a security executive, far from it. Some of my best intelligence comes from developer types, don't ignore them.
Build your trainers, your cadre and have those people lead by taking on smaller groups explaining who is doing what, giving examples of what is seen, stopped and let everyone take credit when due and failure with lessons learned when we fail. What are the symptoms you see with say XorDdos or early ransomware. New grads particularly expect management teach them everything or they get frustrated and leave.
Your never going to break the whack-a-mole mentality unless you train your team to be proactive enough to feel comfortable looking for those things that go bump in the dark. You want a seat at the big table - lead, stop following.
We want many eyes looking to disrupt the bad actors out there but tend to over rely on one or two key team members. Regardless of the technologies available we need as many eyes looking for these possible incidents and make it a positive part of the job, the team not "its not my job" mentality. That's what I am getting at. Tech is the easy part.
Hope that helps.
Cyber-attacks can take varying forms including amateur hacking, "hacktivism," ransomware attacks, cyber espionage, or sophisticated state-sponsored attacks. These attacks have the potential to cause internet or utility outages, leak or delete sensitive data and information, compromise critical infrastructure or services, or cause physical destruction.