Mike’s bold perspectives and irreverent style are invaluable as companies determine effective strategies to grapple with the dynamic security threatscape. Mike specializes in the sexy aspects of security, like protecting networks and endpoints, security management, and compliance. Mike is one of the most sought after speakers and commentators in the security business and brings a deep background in information security. After 20 years in and around security, he’s one of the guys who “knows where the bodies are buried” in the space.
Starting his career as a programmer and a networking consultant, Mike joined META Group in 1993 and spearheaded META’s initial foray into information security research. Mike left META in 1998 to found SHYM Technology, a pioneer in the PKI software market, and then held VP Marketing roles at CipherTrust and TruSecure – providing experience in marketing, business development, and channel operations for both product and services companies.
After getting fed up with vendor life, he started Security Incite in 2006 to provide the voice of reason in an over-hyped yet underwhelming security industry. After taking a short detour as Senior VP, Strategy and CMO at eIQnetworks to chase shiny objects in security and compliance management, Mike joins Securosis with a rejuvenated cynicism about the state of security and what it takes to survive as a security professional.
Mike published “The Pragmatic CSO” in 2007 to introduce technically oriented security professionals to the nuances of what is required to be a senior security professional. He also possesses a very expensive engineering degree in Operations Research and Industrial Engineering from Cornell University. His folks are overjoyed that he uses literally zero percent of his education on a daily basis. He can be reached at mrothman (at) securosis (dot) com.
(DevSec)Ops vs. Dev(SecOps) I just got back from the Boston DevOps Days. I really enjoy hanging around DevOps and cloud people. The energy of these conferences is great, and they are genuinely excited about transforming how their organizations build and deploy applications. Many don’t have a negative perception of security folks, but they don’t really understand what security folks do either.
Our last post explained Continuous Contextual Content as a means to optimize the effectiveness of a security awareness program. CCC acknowledges that users won’t get it, at least not initially. That means you need to reiterate your lessons over and over (and probably over) again. But when should you do that? Optimally when their receptivity is high – when they just made a mistake. So you determine the relative risk of users, and watch for specific actions or alerts. When you see such behavior, deliver the training within the context of what they see then. But that’s not enough.
As we discussed in the first post of our Making an Impact with Security Awareness Training series, organizations need to architect training programs around a clear definition of success, both to determine the most appropriate content to deliver, and also to manage management expectations. The definition of success for any security initiative is measurable risk reduction, and that applies just as much to security awareness training. We also covered the limitations of existing training approaches – including weak generic content, and a lack of instrumentation & integration, to determine the extent of risk reduction. To overcome these limitations we introduced the
We have long been fans of security awareness training. As explained in our 2013 paper Security Awareness Training Evolution, employees remain the last line of defense, and in all too many cases those defenses fail. We pointed out many challenges facing security awareness programs, and have since seen modest improvement in some of those areas. But few organizations rave about their security awareness training, which means we still have work to do. In our new series, Making an Impact with Security Awareness Training, we will put the changes of the last few years into proper context, and lay out our thoughts
After considering the challenges of existing network security architectures (RIP Moat) we laid out a number of requirements for the new network security. This includes the needs for scale, intelligence, and flexibility. That’s all well and good, but how do you get there? We’ll wrap up this series by discussing a couple key architectural constructs which will influence how you build your future network security architecture. But before we go into specifics, let’s wrap a few caveats around the architecture. Not everything works for every organization. There may be cultural impediments to some of the ideas we
In our last post we bid adieu to The Moat, given the encapsulation of almost everything into standard web protocols and the movement of critical data to an expanding set of cloud services. Additionally, the insatiable demand for bandwidth further complicates how network security scales. So it’s time to reframe the requirements of the new network security. Basically, as we rethink network security, what do we need it to do? Scale Networks have grown exponentially over the past decade. With 100gbps networks commonplace and the need to inspect traffic at wire speed, let’s just say scale is towards
The young people today laugh at folks with a couple decades of experience when they rue about the good old days, when your network was snaked along the floors of your office (shout out for Thicknet!), and trusted users were on the corporate network, and untrusted users were not. Suffice it to say the past 25 years have seen some rapid changes to technology infrastructure. First of all, in a lot of cases, there aren’t even any wires. That’s kind of a shocking concept to a former network admin who fixed a majority of problems by swapping out patch
Now that you’ve revisited your important use cases, and derived a set of security monitoring requirements, it’s time to find the right fit among the dozens of alternatives. To wrap up this series we will bring you through a reasonably structured process to narrow down your short list, and then testing the surviving products. Once you’ve chosen the technical winner, you need to make the business side of things work – and it turns out the technical winner is not always the solution you end up buying. The first rule of buying anything is that you are in
Now that you understand the use cases for security monitoring, our next step is to translate them into requirements for your strategic security monitoring platform. In other words, now that you have an idea of the problem(s) you need to solve, what capabilities do you need to address them? Part of that discussion is inevitably about what you don’t get from your existing security monitoring approach – this research wouldn’t be very interesting if your existing tools were all peachy. Visibility We made the case that Visibility Is Job #1 in our Security Decision Support series. Maintaining sufficient visibility
When we revisited the Security Monitoring Team of Rivals it became obvious that the overlap between SIEM and security analytics has passed a point of no return. So with a Civil War brewing our key goal is to determine what will be your strategic platform for security monitoring. This requires you to shut out the noise of fancy analytics and colorful visualizations, and focus on the problem you are trying to solve now, with an eye to how it will evolve in the future. That means getting back to use cases. The cases for security monitoring tend to fall into