1 Raindrop

Which Kind of Security Do You Want?

I have written in the past that the word "security" is harmful:

Security is an overloaded and misused term and should be sunset. In development projects, words have value when they enable people to discuss design concepts and tradeoffs. Ask five different people to define "security" and you are likely to get six different responses.

Depending on what type of business type your enterprise is, there may be widely varying security concerns. John Hagel writes that businesses are moving towards three distinct types:

Infrastructure management businesses (IMB) - high volume, routine processing businesses - think of contract manufacturers, logistics providers and call center operators as relatively pure play examples of these businesses

Customer relationship businesses (CRB) – businesses that get to know individual customers extremely well and, based on that understanding, help to access relevant resources for these customers – relatively pure play examples of these businesses include large advisory firms that help large enterprise customers decide what form of IT outsourcing to pursue and help these large enterprises to evaluate and negotiate with the right mix of outsourcing service providers.

Product innovation and commercialization businesses (PIC) – businesses that focus on developing innovative new products and services, getting them into market quickly and accelerating adoption of the products - think of semiconductor firms operating without their own fab facilities as relatively pure play examples of these businesses.

Given Hagel's business definitions and our familiar building blocks for security - confidentiality, integrity, and availability - what would we see as some general priorities for security by business type? Below is a rough ranking of what are some general concerns by business type.

I think this is an accurate reflection of many infrastructure and customer relationship companies, Innovation is a little slippier - Google has one set of concerns while a biotech has totally different. In any case they are not the same. Furthermore, the union of "perfect" confidentiality, integrity and availability is practically impossible, as your mechanic would say "choose any two". So if you can't get all three, then the next thing to look at is priorities. This may cause some brutal choices, but it does focus your efforts to identify pragmatic ways to move forward on high priority "security" concerns, more than just a general "security" strategy.

Lecture of a Lifetime

This is a valuable lecture - Randy Pausch, a computer-science professor at Carnegie Mellon University, has terminal cancer. He said goodbye with one last lecture called "How to Live Your Childhood Dreams," describing his journey and the lessons learned.

MinneSec next week

Next Tuesday, 10/2, is the second MinneSec meeting at The Local. See details here. Like other CitySec's this is not a vendor driven thing, but a meetup for Twin Cities security folks to meet, talk, and generally hang out.

We're Number 1

This is something I have been saying for a long time, pound for pound this is a really exceptional business climate in Minnesota. Minneapolis came in first for top city for business. How did your city do?

Big, diverse firms The Twin Cities region has a high concentration of massive and diverse Fortune 1000 and S&P 500 companies. It also has a significant number of Forbes 400 private companies. Further, Minneapolis-St. Paul has a healthy array of up-and-coming companies on the Russell 2000 index. And it has more small businesses per capita than just about any other city.

The Twin Cities area was the only one of 50 metro regions examined by MarketWatch that placed in the top 12 in all five of those categories, giving it what proved to be an insurmountable lead. It also placed fourth in a check of unemployment statistics.

We left Colorado to move here, in part because it seemed like a better business climate. Guess I was right, Denver came in at #2.

Next Minnesec is two weeks away

Achtung - Twin Cities security geeks - next security meetup is 10/2 at the Local. More details.

Secure Coding - Getting Buy In

It can seem overwhelming for security people who are typically housed in a separate organization, to begin to engage with software developers and architects to implement secure coding practices in an enterprise. While the security team may know that there are security vulnerabilities in the systems, they have to be able to articulate the specific issues and communicate some ideas on resolutions. This can be a daunting task especially if the security team does not have a prior workign relationship with the development staff, and understand their environment.

To begin with the security team must understand the system architecture - the key applications, databases, user repositories and so on, the security team must also understand the development proces - note NOT the one on paper and ppt, but the way software actually gets built in the enterprise, finally the security team should understand the tools and technologies that are in use to find cost effective ways to improve the security in the system.

The task seems daunting also because there are so many developers compared to security people. I am here to tell you though that you don't have to win over every last developer to make some major improvements. In my experience a small percentage of developers write the majority of code that actually goes live. The lead developers (who may be buried deep in the org charts) are the ones you need to engage, in many cases they really don't want to write insecure code, they just lack the knowledge of how to build better. Once you have a relationship (i.e. that you are not just there to audit and report on them, but are there to help *build* more secure code) it is surprisingly easy to get security improvements into a system, especially if the design is well thought and clearly articulated. You don't have get the proverbial stardotstar, each and every developer on board to make positive improvements, it can be incremental. See some more specific ideas on phasing security in the SDLC here. In meantime, with security budgets increasing 20% a year, use some of that money to take your top developers out to lunch.

Way to tell you are on a project that's likely to fail

Key indicators:

* The project has been "rebranded" or renamed
* None of the requirements have changed
* None of the participants have changed

Web Services Security Training

I am conducting a Web Services Security training at OWASP App Sec, Nov. 11, 12 in San Jose. This is the two day version of the class which looks at assessing vulnerabilities in Web Services and building more secure Web services apps. Note, we are also doing a full Web Services track at OWASP App Sec this year. The speaker list is still coming together, but it is very good. To be announced shortly.

I am also doing a Web services security tutorial at ACSAC, Dec. 10 in Miami; I will be co-presenting with Anoop Singhal from NIST, which just released its Guide to Secure Web Services.