Drawing Parallels Between Non- IT and Security Engineering Principles (Part 2 of 2)

By James Robinson ·

Continuing on from my last blog post; I was considering non-IT engineering/architecture principles I read in 101 Things I Learned in Architecture School by Matthew Frederick and how they apply to security engineering.

Principle #4: As the design process advances, complications inevitably arise.* Architecture is great, however it is only architecture. When moving into design and engineering/implementation there will always be issues that arise. A good architecture sets the stage but should also deliver a framework and intent that can be used going forward. If the specific architecture does not work, the intent should still be carried forward and reflected in revised designs.

Principle #5: Being process-oriented, not product-driven, is the most important and difficult skill for a designer to develop.* Most of us in solution engineering come from a technical background. As we grow we dig deeper into technology until we meet a tipping point where our technical skills need business logic and concepts applied to them. This is part of the maturing process from engineer/analyst to designer, architect, and security lead or department head.  In the model I created below there are a number of things that happen if process is not part of the solution, including inconsistent operation, no ability to execute and no defenses.

People_process_tech

Principle #6: If you can’t explain your ideas to your grandmother in terms that she understands, you don’t know your subject well enough.* At the end of the day there are a few items we must all master to succeed in any accomplishment we drive towards. As IT security professionals we too often get caught in the weeds – great within the right audience and team – but can hinder our ability to effectively communicate our point to an audience outside of the security domain. When explaining security to a business leader I always strive to convey the message in terms they understand and resonate with them. Terms like “cyber kill chain,” which I enjoy using with security peers, is an industry term and something others may not understand, causing my point to fall on deaf ears.

Principle #7: Improved design process, not a perfectly realized building, is the most valuable thing you gain from one design studio and take with you to the next.* I wanted to end with this one because it is good career advice and helps us to be better at principle #1, “Our experience of an architectural space is strongly influenced by how we arrive in it.” If security is something you enjoy you should always challenge yourself and learn. Most of us will not stay with the same “design studio” or security shop for the entire span of our career. We should learn from our current organization, do the best our abilities allow us, and in our next endeavor remember to look for areas where we failed or could have done better when faced with a solution to design.

* Source: 101 Things I Learned in Architecture School, Matthew Frederick

James Robinson

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.