Thinking about enterprises

The below was posted to a private mailing list in which we were debating whether software sources should be drastically restricted in enterprise environments. After I made the post below, I was asked to put it in a public location for wider review and consideration.

I’d like to say I’ll do more posts like this and try to revive this blog, but who knows what the future holds.  ;)

Let’s pause for a moment and think about what an enterprise actually is before we blindly follow a control-based approach. One of the problems in our industry is that we tend to drive for stronger and stronger controls and often forget that our job is to protect the business, not to control the users.

Most enterprises have a complex history that started in small business. As a small business grows, it encounters challenges of scale and one approach to scaling is to make everything the same. However, there is a tradeoff to doing that. Yes, it is easier to manage a monoculture environment, but as with monocultures in nature, if everything is the same, it’s a lot easier to attack. There is also a massive trade-off in terms of flexibility. When all the systems are locked down, workers must follow the pre-determined workflow to get things done. Think about that that means.

As a small business, it is possible to compete against the big players because you can be flexible and adjust the work as the work demands. You may make mistakes, but since you are moving so much faster, you can often screw up and recover faster than your enterprise competitors can complete the first round. This is a huge business advantage and it is what allows, over time, a small business to grow bigger and bigger to such a point where the pain of managing the flexible infrastructure exceeds the value that flexibility can bring, and they start to lock things down.

The problem is that that growth perspective is limited. The growth of startup -> small business -> large business -> enterprise is capped by the size of the economy in which it is growing (like a goldfish in a tank). This means that, as time goes by, the top end of the market gets full of enterprises. There’s not enough cash there for them all to survive, so enterprises at a certain size and stage must begin to re-invent flexibility so they can begin to out-compete the other enterprises around them.

This is a driving factor to why workers try to bypass security controls. They’re not just sitting around trying to think of ways to make your life miserable. They have strong incentives to make their customers happy, because that’s what gets them paychecks and bonuses, and helps the enterprise to stay viable. When security controls get in the way of that, they’ll look to cloud services, downloaded software, and other types of shadow I.T. If you do not support their needs, they will work around you, and security will be viewed as a group that hampers their success. That’s when they start to resist all new suggestions and creating a very difficult environment. The desire of the security team to leverage all sorts of layered controls, but without a concept of what’s actually being protected, is what supports the concept that “Security doesn’t understand the business”, which works against us all.

The truth of the situation is that most enterprises are in life-and-death struggles with other businesses and the ability to leverage the appropriate tools is a critical element of success. In any fight, the side that brings the best weapons and knows how to use them will often be the side that wins. If you force your users to bring knives to gun fights, you’re going to run out of users awfully fast. To use a more modern example, insurgent fighters use whatever they have available, in whatever ways they can, to fight. Professional armies, however, are limited to the pre-determined set of tools, that have been vetted and supplied (often by lowest bidder). As recent history has shown, professional armies are not all that effective against insurgents – because the scope of engagement is fundamentally different.

The same scope of engagement exists between small business and enterprises, and if you hamper your users, you are putting them in a position to be beaten by everyone else. Sure, you’ll be highly successful in projects that require only the set of tools you have pre-approved … but once you’re at that stage, the work can be automated and you may well find customers leaving as they find other ways to meet their needs outside of working with your enterprise.

To succeed, you need to allow for flexibility. This means building a less rigid and more resilient security design that allows people to use downloaded software and cloud services. Perhaps the process involves a renewed recognition that bad things happen and building out recovery processes, perhaps you put more effort into monitoring and detection, perhaps you segment everything at the network level and use encryption to isolate data. There are a great many tools at our disposal that can integrate with the business without reducing the entire world to a binary “yes you can do this, no you cant do that” dichotomy.

In particular, the concept of vetting is problematic. I talk to a lot of security teams that are focused on vetting third parties – but in a lot of cases, their work doesn’t matter, because the business has already decided to proceed. It may be better to, instead of vetting from a “yes/no” perspective, vet around the concept of “if this vendor were to be breached, based on how they integrate with us, how could it hurt us and do our recovery mechanisms sufficiently protect us?” Outsourcing, whether to a service or just using software you didn’t develop, involves risk. But market-based reward also involves risk. Risk is not, in of itself, a bad thing. It just needs to be balanced against what the enterprise is trying to do. The goal is not to maximize safety. The goal is help move the business into a position to succeed, where one of the many factors that could hamper success is a lack of information security.

Remember that “keep the bad guys out” is only half of security. The other half is “while allowing the good guys to get stuff done”. We, as an industry, need to focus more on the latter.

New Book: Breaking In to Information Security

It’s been a while since I’ve posted.  More news will come soon, I am sure.  However, for now, I’d like to point you to a community project.

Anthony J. Stieber and I are working on a new book and, to make it the best we can, we want the story of how you got started in information security.

Please feel free to pass this link around to others (retweet it, whatever).  If you now have or have had a job in InfoSec, we want to hear from you.

We’re doing this because we’re increasingly asked how to “break in” to the field of information security. Robin Wood kickstarted the process with his survey , and many of us have done the one-on-one mentoring thing. However, we feel that it’s time to draw a line in the sand and document the process “thus far”. A clear path to entering the information security field can save years of inefficient or unethical effort.

Our book uses a simple “Learn, Do, Teach” core that guides readers to become useful community members. The core idea is to learn constantly but also to contribute and later teach others and guide them through the same process.

We recognize that few careers follow direct paths. To make the book the best we can, we ask you to share your career path with the community. These short “biographies” will show how real people have broken into information security. As a thank you for helping us with this book and to contribute to the community, each author will donate 50% of the book royalties to Hackers for Charity .

If you would like to help with this project, please send to infosec.career.stories -at- gmail.com a short description of your story, or if you prefer, at your convenience we’ll do an informal interview.

Again, please forward to anyone with an information security career story.

Feel free to ask any questions you like in the comments below or contact me directly on Twitter.

Book Review – Blackhatonomics

Syngress was kind enough to provide a free copy of this book for me to review.

Blackhatonomics was an interesting book to read. As one gets older and more skilled in one’s field, the portions of books that are new become smaller and smaller. I had high hopes that this would be a detailed dive into the economics of criminal activity and, in that, I was disappointed. There is little here that was new to me. I didn’t get into the content I wanted until Chapter 8 – “Pawns and Mules” and then stuff got good in Chapter 9 – “Globalization: Emerging Markets Aren’t Just for Traditional Investors Anymore”.  Chapter 10 then discusses crime in America and Chapter 11 focuses on the world.  Then, alas, we’re at the conclusion.

Really, what I had hoped for was a text written by an economics expert giving people familiar with cybercrime some detail as to how micro- and macro- economics work in that space.  What I got was a book aimed at people unfamiliar with both cybercrime and economics. This isn’t bad.  It’s a good book for people who are just getting started.  It’s just not quite what I was looking for.

I’ve stopped rating books. It’s unfair to the authors to ding them because their book didn’t meet my expectations when the book is marketed by someone else entirely. Really, this book is a good intro for a lot of people. If you have less than two years in the Security industry or have never actually worked a hacking-for-profit case, it’d be good for you.  If, however, you have a ton of experience and have worked with law enforcement to help your client, there’s little in here that’s new.

And really, that’s not the authors’ fault. What I want is up-to-date information about criminal economics, but the economic data of current crime is often locked up in court and spread across numerous countries and jurisdictions. Can we guess at trends? Sure.  Can we plug data into economic models and demonstrate what’s going on? Not really. We can solve this by creating economics models. I’ve been toying with playing with ideas from Complexity theory and considering running scenarios using cellular automata to model different economic models in worlds where there is a theft component. I was hoping that this book would have done the research so I wouldn’t have to. That was, in retrospect, a rather ridiculous expectation.

So in the end. the question is “do I read it, do I ignore it or do I get it from a library?”

If you are just starting in your career, read it.  It has good data and will help get you started.

If you’ve been at this for a while but are not directly involved in law enforcement, get it from a library. Skim chapter 8. Read chapters 9 through 11.

If you’re involved in law enforcement, there is likely little in this book that will help you.  You can skip it.