SEC Guidance: A Cross-Disciplinary Perspective by Steven Fox

In continuation of our series of discussions on the new SEC Guidance, I was joined by Steven Fox, CISSP and QSA. He is a security architecture and engineering advisor at the U.S. Department of the Treasury. Mr. Fox brings a cross-disciplinary perspective to the practice of information security, combining his experience as a security consultant, a senior IT auditor, and a systems engineer with principles from behavioral and organizational psychology to address security challenges. He is also a syndicated blogger covering IT governance, risk management, and IT business fusion topics. Steven published a blog post earlier this month with an overview of his thoughts on the new guidance, and you can listen to his podcast interview in the video at the end of this post.

Such a great bio on you… Can you give us a little bit of background about the whole psychological aspect combined with IT? We don’t see that a lot.

Well, I’ve always been something of a geek. Early in my IT career, ever since high school, I taught myself how to program in assembly, and the high-level languages as well. As I got to be more and more technical, I began to realize that it wasn’t just all about machines – people use machines.

So, I decided to take a break from working with systems for a while, to understand the user in greater depth. I majored in psychology with a minor in biology, so a lot of my friends call me a “psycho biologist.” That led me to really understand the interface between the human and the machine, which later led to me entering the field of information security.

What a great combination. Let’s get into our topic today, the SEC guidance. What’s this all about?

Basically, the SEC, back on October 13th, released pretty detailed guidance. But what it boils down to is suggestions – that companies disclose to either potential investors or current investors the materiality of security instance on the business.

For example, everything that’s been happening with RSA has a very clear material impact on their business, as well as their clients. Investors that were either currently part of the RSA stock, they had to wonder, “Well, what is the future of this stock? What impact are these incidents having on my investments?”

The SEC thought, “We have to find a really good way to guide business owners out there on how to communicate with their investors about incidents,” and that’s what this whole guidance really is about.

How is this really different once put into practice when compared to, let’s say, something very prescriptive like PCI or something very descriptive like Sarbanes-Oxley? What are the differences here when you juxtapose these things?

Sarbanes-Oxley and PCI are all about setting a common language for people to talk about security. It’s a business language or lexicon, if you will. In the PCI space you have retailers that use credit cards. There they simply try to find a common way to describe what is a threat, what is a risk, what does that look like and what is going to impact me at a materiality level. The same goes with Sarbanes-Oxley. There you’re talking about responsibility in reporting for financial companies and privately owned companies as well.

What’s different here is the SEC is trying to get people to talk. If something huge happened in your environment, if there was an incident that’s going to impact your business operations at a significant material level, obviously that’s going to impact the faith that potential investors have in you, but also the future viability of a stock for current investors.

Here the SEC is trying to get the companies to be transparent about what’s going on after an incident. Whereas, being prescriptive is more trying to set an environment to mitigate the impact of an incident.

As we wrap up here, how do you think IT organizations should react to this? Also, how do you feel an executive team should react to this? Are there steps that they should be taking proactively at this point or is it just something that they need to familiarize themselves with if and when something does occur?

The first step is for the business stakeholders to understand that the IT security practice has an impact on their business. They need to understand that these people that are working within the IT areas of their business have an impact on the stock. This is a real opportunity for the people in the IT security function to develop more business savvy and be able to communicate what an incident really means to the business.

I just came off of a CISO conference hosted a week ago. There, I advised CISOs in the audience to place one of their representatives within an incident response team so they can communicate directly and immediately with IT professionals to evaluate what an incident means on a business level. They can then take that perspective to the board and respond to it quickly while an incident is addressed on a technical level.

Now, another thing is, at a business level, you also have to think about the impact that this is having from the Dodd-Frank rule that was passed a couple years ago having to do with whistle-blowers. Here, what’s been happening with that regulation in the financial sector is, you might have someone that’s aware of a financial incident that has materiality in the company, but it was never exposed either in a prospectus or an annual report.

In those instances, that individual can then report that to the SEC. Think about what that might mean for a company that had a material incident that was never reported. You might have future incidents where a person from the incident response team sees that the board never responded to the recommendations and then this person might go to the SEC and report a company that way.

There are larger-scale implications that I foresee in the next two or three years as this matures and companies begin to really process what to expect from it.

Great insights, great perspective. Well, Steven, thanks so much for joining us on our program.

Well, thank you. I look forward to being involved in future broadcasts.

You can learn more about the Security and Exchange Commission’s Disclosure Guidance on Cybersecurity on their website, and be sure to read Steven’s Security Connected blog post on the topic. For future updates, as well as up-to-date McAfee news and events, follow us on Twitter at @IntelSec_Biz.

The opinions expressed in this blog are those of the author and do not necessarily reflect the views of McAfee, Inc. This blog is for general information purposes and is not intended to be and should not be taken as legal advice.

Leave a Comment

twelve + twenty =