I had muted expectations when I stumbled upon a podcast by Stewart Baker.
“A podcast by a lawyer on the topic of cyber security? Should be as interesting as reviewing previous year tax returns”, I thought to myself. “I’ll give it 30 seconds”, as I looked around for something, anything to divert my attention.
With nothing in sight, I queued up the podcast… and was pleasantly surprised. It is in fact not the most boring podcast in the world, far from it.
Give it a listen and see if you agree:
Intuitively I knew it made a difference. The “why” of why infosec pros get up in the morning and “do what we do”.
Many times working “security” we get consumed by the fires of the day and forget (or refuse) to take time to recognize why we ultimately subject ourselves to the pain around solving the very complex and serious security issues of the day.
Recognizing in a very tangible way that my mindset/philosophy is ultimately responsible for my successes and failures has had a profound positive impact on my life. I review my work philosophy often. I recognize that it is not perfect or permanent. I use it as a defense and as inspiration.
Stuart’s Work Philosophy
“I believe in the positive transformation of the world through the creation and application of new technologies. I work because I make a positive difference in the world by applying top down, leadership led, security solutions that enable leaders and their people the freedom to innovate in the face the many security roadblocks and unrealized risks that exist today.”
Jeff Olson in his book “The Slight Edge” states: “Your philosophy CREATES your ATTITUDE, your ACTIONS, your RESULTS, which create your LIFE.”
Create your own philosophy using these simple steps:
- Write down “why” you do what you do professionally.
- Map the “why” to your larger life and overall goals, plans and dreams.
- Review it often.
There are few opportunities more impactful then having the opportunity to be immersed for a time in a movement that transcends profession and helps to answer the question: “Why do I exist?” Black Hat is one of those rare opportunities for me, Dan Geer is one of those men. His humble thought leadership, vision and knowledge are both inspiring and impactful.
The full text of Dan’s 2014 keynote is available here.
Geer on humility
“There are three professions that beat their practitioners into a state of humility: farming, weather forecasting, and cyber security. I practice two of those, and, as such, let me assure you that the recommendations which follow are presented in all humility.”
Geer on cyber security
“Cyber security *is* being taken seriously, which, as you well know is not the same as being taken usefully, coherently, or lastingly.”
Geer talking about veteran (not old!) security pros
“Those of us who were in the game early enough and who have managed to retain an over-arching generalist knowledge can’t be replaced very easily because while absorbing most new information most of the time may have been possible when we began practice, no person starting from scratch can do that now.”
Geer on the expansion of government
“Over my lifetime the public expectation of what government can and should do has spectacularly broadened from guaranteeing that you may engage in the “pursuit of happiness” to guaranteeing happiness in and of itself.”
Geer on the right to be forgotten
“After a good amount of waffling, I conclude that a unitary, unfakeable digital identity is no bargain and that I don’t want one. I want to choose whether to misrepresent myself. I may rarely use that, but it is my right to do so. If that right vanishes into the panopticon, I have lost something and, in my view, gained next to nothing.”
Geer on abandonment
“If I abandon my storage locker, then it will be lost to me and may end up on reality TV.”
Key Takeaways: The AWS shared responsibility model is a vehicle for explaining security control responsibilities between AWS and customer and is not a security panacea for vendors developing on the platform. Closely examine vendor governance controls, specifically vendor management programs to determine if the additional responsibilities of shared responsibility are accounted for in their security program.
In 2012 Amazon pioneered a cloud security concept they now call the “Shared Responsibility Model”. This concept was borne out of the need to clearly communicate the line of demarcation between AWS security responsibilities and ours (loyal AWS customers).
The concept is as obvious as it is useful, if used for good rather than evil.
I use the term frequently to explain to auditors, engineers, c-level folks and basically anyone who will listen that Amazon is responsible for technical security controls from the “concrete through the hypervisor” and explain that as an AWS customer we are responsible for everything else. Everything else includes; the operating system, network and firewall configuration, our software/platform, and of course our data. Here is a diagram taken from the AWS Security Best Practices whitepaper available here. (Evil follows the diagram.)
Now for the evil. I’ve noted on more than one occasion vendors invoking the AWS shared responsibility model to absolve themselves of any responsibility for the security layers that Amazon is responsible for. This is flat wrong and irresponsible.
The vendor is most certainly still responsible for security throughout the entire AWS stack, but what has changes is the type of control. What was a technical control now becomes a governance control.
Scrutiny of their vendor management program (if they have one) should ferret out whether they have a clue as to the difference.
As security leaders we spend our working lives managing risk, being bombarded with very real threats and vulnerabilities and the vendors who can “solve” them, all while struggling to influence and instill positive change in our own dysfunctional organizations. From time to time we must step back to own and celebrate the fact that the even the small positive steps for good we take today lay the foundation for a more secure future that none of us alive today can even imagine.
There are a couple of people that I want to take the time to highlight; Ernest Mueller @ernestmueller and Tim Virtue @timvirtue.
Ernest’s thought leadership, publication and iteration of “What is Devops” has been exceedingly helpful in my quest to both define devops in my own head as well as communicate the vision and future of operations/development/cloud to others.
Tim is the first security leader that I know of that has presented devops in the context of security. I had the opportunity to listen and speak to Tim this year at SecureWorld Houston. A slidshare of his presentation is here.
The fact that both of these guys are in Austin? Bonus!
My take on agile/devops? relative to security? The fundamentals of information security will remain the same. Devops will demand that we as security leaders, change our tactics, and speed the heck up, to retain any relevancy in the face of the insane pace that devops and agile processes facilitate.
While doing my best to absorb a small portion of the wealth of useful information found in Dr. Kenneth Brown’s Great Courses: Influence Mastering Life’s Most Powerful Skill, I had an ah-ha moment that I wanted to pass along.
Dr. Brown states that exerting influence will always result in one of the three following outcomes; CONFLICT, COMPLIANCE, or COMMITMENT.
CISO’s and other security pros who have spent years in the security trenches are more than familiar with the first two; conflict and compliance. The bulk of our time it seems is spent squarely in between.
If we have finally exerted enough influence successfully managing past conflict, and adeptly wielding the compliance ax to “be compliant”, we tend to call it a win and move on.
The ah-ha moment for me was the realization that the persistent, nagging feeling of uneasiness I have carried since my early days of security leadership is the “commitment gap”, the gap that exists between compliance and commitment.
Failing to achieve commitment from stakeholders, results in, at best compliance. While certainly better than conflict, compliance by itself is inadequate and a hollow victory to be sure.
Commitment is a high bar, and unfortunately not always something that can be obtained, but it should always be the goal.
Do you agree? I’d love to hear about your successes, challenges and thoughts on this or any other information security related topic.