Vice President, Third-Party Risk Management
As vice president, third-party risk management, Robinson oversees Optiv’s Third-Party Risk Management practice which includes the development and operations of TPRM-as-a-Service and Evantix. During his tenure at Optiv, he has worked as a core contributor around strategic internal initiatives including threat management, risk management, third-party risk management, vulnerability management and data program protection. He also develops and delivers a comprehensive suite of strategic services and solutions that help chief experience officer (CXO) executives evolve their security strategies through innovation.
Drawing Parallels Between Non- IT and Security Engineering Principles (Part 1 of 2)
I always look for interesting parallels between things we have learned or practiced in other industries and how they can be applied to the security discipline. Recreating the wheel is not always needed; sometimes we just need to know how the wheel was modified for other uses and if those modifications work for us too.
A few weeks back, while at the airport waiting for my flight, I stopped in a book store and picked up 101 Things I Learned in Architecture School by Matthew Frederick. While thumbing through it I was surprised at the number of non-IT engineering/architecture principles I came across that many of us in software and systems engineering use every day. I purchased the book and read on, and was able to draw seven interesting parallels between the principles that could be applied to both industries.
Principle #1: Buildings must be designed to withstand stress from earthquakes or other events.* An interesting concept not used enough in IT security architecture is designing for failure. This is illustrated in the defense in depth principle, where multiple security controls are layered throughout a system, making it more difficult for an adversary to complete a successful attack. The layers act as a back-up if a single control fails or a vulnerability is exploited.
This concept is applicable to any of the three elements of a successful security strategy: people, process and technology. As an example focused on the “people” element, say an incident response team is comprised of three individuals, all good consultants, with two working a case at any given time. What if on a certain day one person is sick (people fail too), how will the loss affect the team’s ability to respond to other incidents? Maybe there is a junior-level consultant interested in security monitoring and IR, who can work as an emergency backfill; maybe you use your MSSP to handle the incident more in-depth; you must be prepared for the failure.
Principle #2: Our experience of an architectural space is strongly influenced by how we arrive in it.* This holds true in security engineering. Many of us in security arrived at our careers from other paths. I came from a computer networking background in a very large enterprise which shaped my current thought process; enterprise controls and scales are something I think about in every architecture review I put forward. Others may have come from software engineering backgrounds with a developer mindset; they may focus only on the application and take the infrastructure for granted. To build a well-rounded team, a manager should hire resources that come from different backgrounds so the group is able leverage their perspectives and have a complete view security.
Principle #3: Engineers tend to be concerned with physical things in and of themselves. Architects are more directly concerned with the human interface than with physical things.* In security many engineers will focus on certain components of security. Some may focus on the OS, some on the application, and others on the incident response. As an architect we must think about all things. We must think about the way the solution will be used and how all aspects of security should be aligned to complete the user’s or application’s objective while maintaining all disciplines of security.
Stay tuned for my next blog post for information on the remaining four principles and how they apply to security engineering.
* Source: 101 Things I Learned in Architecture School, Matthew Frederick