LolOWASP
Did you ever wonder what would happen if you made a hybrid between lolspeak and the OWASP Top 10? Pravir Chandra and I wondered the same thing. Teh result? icanhaspwn, of course.
« March 2008 | Main | May 2008 »
Did you ever wonder what would happen if you made a hybrid between lolspeak and the OWASP Top 10? Pravir Chandra and I wondered the same thing. Teh result? icanhaspwn, of course.
It is tough to sell the idea of jogging and broccoli when people want cheeseburgers and malts. Books about breaking into systems sell a lot more than books about securing systems so they are harder to break into.
But often its the boring stuff that is most important, I like reading Robert Kaplan, and he comes up with some good stuff, but he clearly is after a *story*. Here is a post on this by Tom Barnett:
Globalization is boringARTICLE
Robert Kaplan on the New Balance of Power, By Trudy Kuehner, April 2008, Foreign Policy Research Institute E-NotesWhy balance of power thinking is so attractive to writers is its essential zero-sumness: any "rise" equals somebody else's loss. As such, analysis can be presented in the desired "who's up and who's down?" format so loved in DC.
The economics, as always with Kaplan, is muted beyond the always underlying subtext of coming resource wars ("Oil! We must have oil, my good sir! "). The stunning rise of globalization's network trade is, sadly, a poor relation in such discussions, because it depresses those who focus on "power" and "competition" and the like. Real integration is boring. There are no imperial corollaries from the 19th century. There's no romance. It just plain sucks. There's no who's up or who's down. No good visuals. Hard to explain. "Great games' sound just so much more exciting.
Oh well, there's always pirates ...
Barnett's books are must reads if you want to have any clue about what is going on in this century. Barnett's first book "Pentagon's New Map" points out the issues when technology and economic integration outpaces security. This book has outsold the follow on "Blueprint for Action" even though when the second was published Barnett was a far better known writer because he just wrote a best seller. The reason as Barnett says is that people love diagnoses, they don't love prescription.
Look at the size of breaker conferences like Blackhat and Defcon, great conferences to be sure, but where is the commensurate builder conference? To the extent there is focus on infosec issues it is mostly on the threats. They are the most fun "there's always pirates ..." and all that, but it really misses the point when there is nowhere near the focus on building secure apps. The closest thing to a big builder conference is OWASP (again a great conference) but even there is a ton of breaker talks. I am not in any way against breaker talks/cons, just want to see more builder focus. Even if its boring to some its still important.
iang made an important point in a comment the other day:
And ... and ... cryptography people don't know much about security, and nore about risks, and risk people don't know about evidence and legal people don't know about user interaction and database people don't know about double entry and accounting people don't know about atomicity and none of any of the above should know anything about hacking 'n cracking.And that's before we get to the business side. What a sorry state we are in :)
No question about it, over specialization creates a lot of problem. Some of this is driven by the increasing complexity of each domain. We get new tools that raise the levels of abstraction so we can work higher level problems (Java programs are not worrying about every little bit of memory, they are writing business logic), but what this also leads to is more complex tooling and so it drives every group deeper into their own specific silo.
Its espcially problematic in infosec because, security is system level property yet when its addressed at all, it is done in a tactical project manner.
It turns out other disciplines have similar issues. Here is a story on Angela Belcher (emphasis added)
CHEMISTRY CALLS ITSELF the central science, but few chemists find themselves at the crossroads of as many disciplines as Angela M. Belcher does. One need look no further than her title—the Germehausen Professor of Materials Science & Engineering & Biological Engineering at Massachusetts Institute of Technology—to get an idea that this self-described materials chemist is doing more than dabbling in the worlds of biology, engineering, and materials science."I love the idea of engineering biology to do nonbiological problems," Belcher explains. Her research takes biological systems, such as viruses and yeast, and guides their evolution so that they build technologically important materials from elements they would never find in their natural environment.
Her convergent approach to scientific research has won Belcher top honors for creativity and originality. In 2004, she garnered a MacArthur Fellowship—commonly known as a genius grant—and in 2006, Scientific American named her the research leader of the year. She also used her biomaterials and nanotechnology know-how to cofound Cambrios, a high-tech start-up in Mountain View, Calif.
"We've been getting really good in the last couple of years at using biology and biological mechanisms to grow and assemble materials and functional devices," Belcher says of her research. Right now she's using this approach to create materials for energy conversion and storage, carbon sequestration, catalysis, and biomedical applications. For example, her lab has coaxed a bacteriophage into building a rechargeable battery from cobalt oxide.
"When I started out, we were interested in making things because they were interesting materials," Belcher notes. "Now we're more interested in making something useful that has an impact. We want to help solve some of the most important problems in society. To do that, we have to learn more about the state of the art, what the problems are, and what the opportunities are in these different disciplines."
To that end, Belcher says that she is always trying to incorporate a diverse range of scientific areas into her research. "I'm on my toes every day trying to understand aspects of these emerging areas," she says. "I'm definitely not an expert in everything, but as our work progresses, I feel we have to raise our level of expertise."
So, what's Belcher's secret when it comes to breaking into a new discipline? "I have no problem admitting I know nothing about something and trying to learn it," she responds. "When we first started working in batteries, I didn't know anything about them, but I was willing to admit that and learn."
It's a tack Belcher has taken since her days as a graduate student at the University of California, Santa Barbara. For her doctoral research Belcher had three mentors—a chemist, a physicist, and a molecular biologist. She followed that up with postdoctoral work in electrical engineering.
Belcher's multifaceted approach hasn't always been looked upon so positively, though. When she started at her first faculty position nine years ago, she says, colleagues told her that she needed to pick a specific field to go into. They said that she should aim to be well-known in one particular area, rather than working at the interface of a number of different disciplines.
Now, Belcher says, it's so much easier to be a scientist taking a multidisciplinary approach. "I look at the graduate applications that come into my departments, and there are students from all different disciplines of science and engineering applying for one particular program. It's so great to see," she says.
"I think that multidisciplinary thinking and approaches are going to go a long way toward making major breakthroughs," Belcher says. "I think that can be key to pushing science forward and solving the next generation of challenges, whether it's in energy, medicine, or the environment."
BELCHER'S OWN RESEARCH GROUP is a living example of this multidisciplinary philosophy. Her students and postdocs come from chemistry, biology, physics, mechanical engineering, civil engineering, biological engineering, and materials science. "I bring students into my group because they're the smartest and most dedicated students I can find. And then, within the areas that I'm funded in, I kind of let them loose," she says.
"They work together and they speak together all the time," Belcher adds. She says she loves to walk out of her office to find her students teaching each other about their fields of expertise. "I select people who get along well together, which is key. I don't like competition within my group. That's always going to happen a little bit, but I like team building," she notes.
Oh, we can learn some lessons here. How much opportunity for improvement would there be if security people, and developers, admitted they didn't know much about the other domains, and began cross pollinating? Evolve, adapt, adept. Yo la tengo! Ya gotta believe.
The worst case scenario of not making these connections across domains is Munger's Fatal Unconnectedness:
What’s Wrong with Economics1) Fatal Unconnectedness, Leading To “Man With A Hammer Syndrome,” Often
Causing Overweighing What Can Be CountedI think I’ve got eight, no nine objections, some being logical subdivisions of a big general
objection. The big general objection to economics was the one early described by Alfred North
Whitehead when he spoke of the fatal unconnectedness of academic disciplines, wherein each
professor didn’t even know the models of the other disciplines, much less try to synthesize those
disciplines with his own.I think there’s a modern name for this approach that Whitehead didn’t like, and that name is
bonkers. This is a perfectly crazy way to behave. Yet economics, like much else in academia, is
too insular.
Anyone who has worked on solving software security problems can relate to this. Consider static analysis, a commonly practiced anti-pattern goes like this.
0. Security people have a nagging suspicion that the developers' code might not be perfect
1. Security people buy the static analysis tool
2. Security people scan the developer's code
3. Security people hold a bug parade with unfiltered results and indulge themselves in "developer waterboarding" broadcasting a bunch of unfiltered findings
The result of this is increased hostilities between the development and security groups (if this is even possible). Many times, the findings are extremely context specific and if the security people barge in with only tools they miss the context, if they engage in developer waterboarding they miss the chance to make a good working relationship.
Here is how I would rewrite it (best case)
0. Security people and developers work to understand basic fundamentals in each other's domains - agree upon evaluation criteria for static analysis tool
1. Security and developers do a POC and select a tool
2. Security and developers refine rules and scan code
3. Security and developers integrate tools in SDL
Some more ideas on static analysis tools specifically here from Messrs. Chandra, Chess and Steven. If a scan runs in a silo, do the results matter?
Mike Rothman has a nice post today
Great, 2.7 million people that have no idea what's going on So what? - It must be good to be the ISC2 nowadays. If you believe the survey they commissioned Frost and Sullivan to do, there will be 2.7 million security professionals by 2012. The survey also goes into a bunch of skills these security professionals need. Amazingly enough getting a CISSP is top of the list. I'm kidding.
Mike' post references this dark reading article called Market's Message to Security Pros: Adapt or Die. I agree with the sentiment, in fact I wrote a post almost three years ago called Message to Security: Evolve or Die.
I think the answer, instead, is for security to operate like a software development team. Develop approaches that allow for rapid prototyping and deployment of ideas, and be able to replace outdated concepts quickly.
Say what you will about software developers (and security people love to throw stones at developers), but they are good at delivering. Maybe its time to start learning from what they do.
Ok, now back to Mike Rothman
I think there will be 0 security professionals in 2012. That's right, ZERO. I think there will be network folks that specialize in security, and also some data center folks and even more application folks that are security specialists. OK, these are word games and a bit of semantics, but I think it's an important point. If anyone thinks their only job is going to be security in 4 years, I suspect they'll end up as a petroleum product sooner rather than later. OK, maybe not 2012, but I'm with most of the big mouth security pundits in saying security as a business will be going away within a reasonable long term planning horizon (7-10 years). So start practicing, "I do secure networks." Not "I do network security." There is a big difference.
I could not agree more with the secure networks instead of network security! This distinction is absolutely huge. I would agree with Mike's conclusion, but I think this is more best case rather than realistic end game. I think there will still be a place for infosec, just that a lot of lower level problems should be removed (best case), by people taking initiative and doing their job.
Another reason I like this approach is that it is asset centric not threat centric, as Butler Lampson says "all trust is local." Software security does not succeed without developer buy in, database security does not succeed without DBA buy in. As Ian Grigg says "Its your job. Do it....Get comfortable with having to learn yet another discipline...You need to be an adept in many more aspects"
I think security is likely to still have a role, perhaps in addressing cross cutting concerns, but a hopeful best case is I build secure networks, I build secure apps, I run secure databases. Maybe the role of infosec evolves to something closer to what Robert Garigue referenced as the Charlemagne - ability to teach and lead across disciplines. The closer to Rothman's zero we get the better off we'll be.
Warren Buffett likes to say "price is what you pay, value is what you get." Like so many of his sayings, it seems simple, but then you look around and you see that common sense is often not commonly understood. This post(hattip mcd) shows how this plays out in my swamp which is consulting
Pricing Strategies:“We do not compete on price. Ever. If we can't compete on value, ability, talent, and, frankly, if we can't create a better value proposition for the client, we don't want their business anyway.”
“We are aware of the potential need to reduce cost to gain access but also believe that the selling process should effectively focus on value and reference capability to deliver.”
Introductory Service Pricing:
“We've found that the first project creates pricing expectations for future projects, and that the work is valued more when it is priced at full rate.”
“The introductory pricing strategy is not necessarily a lower price, but a smaller or pilot project which makes it easier for the client to accept without prior experience with our work.”
I have found all of these statements to be true in terms of sales process where as small, boutique consultants we are constantly having to differentiate our offering between ultra-low cost providers and high cost Big 5 style shops. On the surface either option may appear to be lower risk for clients. The former can save them $ in the short run, the quality may suffer in the end. They may not be able to deliver and the client may have to take on a very hands on role. The Big 5 style may force the client into exorbitant costs, plus they still may not deliver what they client wants or needs. So we are usually stuck in between these two spaces which offer in the security space say firewall jocks (low end) and white shoed auditor types (high end). How we differentiate is value. It makes no sense to even try to compete with the other groups, by the way I am not saying there is not value coming from the other groups, I am just saying the value proposition is different.
If you just look at cost you don't see any differentiator, because we will always be more expensive than body shops (we will always be less than Big 5 as well). One way we prove value is using a fixed cost initial deliverable which can an assessment, training, eval, POC or other. This way the client can realize value for low initial investment and see if where it makes sense to go from there. The value we create frankly is a result partly of our own abilities as much as the places we have been , talented people we have worked with in the past and what we have seen work/not work. This is definitely something you can get sometimes from a Big 5, but we are come at a much lower cost, and we are not answering to six levels of internal mgmt, trying to sell a monster project (consultant fishing expeditions); we are just focused on delivering for the client.
As is so often the case in consulting, Gerald Weinberg figured this out a long time ago. he said "Price has many functions, only one of which is the exchange of money." and "Price is not a thing, its a negotiated relationship."
Gee, that seems like a couple of useful distinctions, which leaves open the following question - Is it a coincedence that both Weinberg and Buffett lived in Nebraska?
So when we define value that we bring we focus on two things - our own experience and a track record of results. A simple example is testimonials from Web services security training, which underscores from the client point of view the value we help to create:
"High quality detailed overview of SOA security standards and approaches. Well thought-out and structured presentation."
- Sr. IT Architect, Fortune 10 enterprise
"The knowledge and transfer was a great baseline and with the additional resources Gunnar made available, made this one of the best one day classes I've taken."
- IT Security Lead, Fortune 10 enterprise
"This class was a thorough and well-organized trek through the current Web Services Security landscape. Going beyond just describing the standards and the options available in the Web Services Security world, this class discusses real-world use cases and offers implementable solutions, best practices, even vendor choices in several key areas. This class provided me with actionable tasks that I took back to my project teams the very next day!"
-Jesse Aalberg, Sr. Enterprise Application Architect, United Healthcare
"The class was distinctly focused on Security requirements and the strength and weaknesses of the various solution approaches we could consider. The result of the course was actionable approaches to providing security in our SOA environment."
-Brad Sillman, Director IT Security, Deluxe Corp.
"Anyone who wants up-to-date information on SOA Security, security standards and best practices should take this class."
-Kevin Beam, Senior Systems Engineer, Union Pacific Railroad
"Good comprehensive overview of subject, standards, and threats"
- Sr.Security Consultant, Ubizen
"The class helped me get my head around what "SOA" and WS-Security is really all about"
- Mike Zusman, Independent consultant
"Topics addressed are timely and relevant. Labs are hands-on and help see concepts in action"
- Jerry Tan, Systems Analyst, DTCC
"This class was concise and covered a majority of the problem set my company is looking at and dealing with."
- Steve Reilley, Technical consultant, Commerce Insurance
"Excellent two day overview of security topics as related to Web Services."
- Daniel Reznick, Information Security, ADP
"Issue affecting most of us today & for those that don't - will soon. Very necessary education and technology."
Aaron Delashmutt
"Great class! Effective and relevant teaching in an area without much guidance."
- Mark DiSabato, Senior Information Security Architect, Roche
"The class cut through jargon to communicate concepts and implementation details."
- Developer, Fortune 100 insurance company
"Good overview regarding SOA Security. Contains new technology like AMQP and REST"
- Lars Loland, Statoil
"The course covered what I had to learn about Web services"
- Sven Vetsch, Dreamlab Technologies
"Very good, eye opening especially for websecurity noob."
-Michael Brandon
"Presenter has very broad and deep technical knowledge on subject. Content: good overview and comparison of SAML and WS-*"
- Security consultant, ING
"Good to learn where our application is vulnerable to attacks and how we can avoid them."
- Application Development Programmer Lead, Fortune 100 Insurance company
"Entirely thorough overview of technology surrounding the use of web services with a 1 day presentation"
- Technical consultant Contextis
"Gave a good overview of the Web services security environment"
- Francesco Degrassi, Emaze Networks
"A great entry point for securing your web services"
- Stig Kluver
"Lots of good technical information about an emerging area that's very useful"
- Rory McClune, HBOS PLC
"This class reinforced the importance of software security assurance to me as it lucidly demonstrated why being 'behind the firewall' is an outdated concept."
-Senior Support Engineer, Software Security vendor
"The area of SOA Security is complicated and youg. A course such as this helps bring it into focus."
-Jayme Frye, System Engineer, Union Pacific Railroad
"Web services security class provided application security concepts valuable for applications audits."
- Mary Ma, IT Auditor, DTCC
"Very knowledgeable coverage of security requirements for Web services."
- David Libershal, Network Security Engineer, Johns Hopkins University Applied Physics Laboratory
"WS/XML security is not a "black art", but you do need to know about it to be able to take it into consideration."
- Applications Specialist, Global 500 manufacturer
"Good overview of techniques worth considering when planning secure apps"
- EAI Specialist, Leading Mobility company
"Brought concepts in very easily understood terms."
-Glenn Bernard, Systems Engineer
"Gives ideas about the latest Web services security standards in the industry"
- Security Coordinator, Global 500 manufacturer
"Class cleared up various WS-* standards and gave great concrete examples of how to build a message using each standard. Very good general thoughts on security groups' role in IT."
- Matt Kasselman, UP Systems Engineering
"I found this very useful as an IT architect in a "security critical environment"."
- Mika Pullinen, IT Architect, Finnish Defense Forces
"Lots of useful information packed in a small amount of time. Good overall picture."
- Jari Pirhonen, Security Director, Samlink
"Gunnar is very knowledgeable about security topics and has a great ability to explain complex ideas using simple, appropriate, and amusing language and analogies."
- Scott Redd, Sr. Project Engineer, Union Pacific
"Excellent instructor who had a good pace to go through the presentation"
- Anna Vaahtokan, Specialist, Nordea
"Good application security principles."
- Tuomas Kivinen, IT Security Specialist, Nordea
"I liked the class quite a bit. I took it in a "survey mode" where I wanted to learn about topics at a high level, and this was accomplished. It was good to listen to those in the class that were much more familiar with SAO than I."
- John Glazeski, Senior Systems Engineer
As the saying goes, the teacher learns more than the class. Well I went out to lunch with some security folks in my class a couple weeks ago and they introduced me to the wonderful world of Lolcats, absolutely brilliant.
Their panel at roflcon sounds awesome as well
Q: What is the takeaway for making awesome? (Pls answer in LOL).Things that become big on the internet are combinations of small iterations on other people’s ideas.
A: Lol + trek, Lol + cat, Lol + Bible, Walrus + bucket. Etc. Take two things people like and shove them together.
A: The Internet can do anything.
A: The idea is bigger than you. You are nothing. You are just the midwife of the idea, helping it into the world.
A: Don’t listen to the haters. Use that time to serve the people that love you.
Just saw here that CXF has graduated to an Apache top level project. I have long been a fan of CXF and Celtix before that. In my SOA, Web services security class we generally use both (and Axis2) to demonstrate concepts and build security into web services.
In terms of comparing security features in CXF and Axis2, it looks like CXF is relying on WSS4J for security services just like Axis2. WSS4J gives a nice way to program to XML Signature and XML Encryption (which is provided by xmlsec), but it looks to be implemented differently in CXF where you are coding properties for WSS4J interceptors
outProps.put(WSHandlerConstants.ACTION, "Signature"); outProps.put(WSHandlerConstants.USER, "myAlias"); outProps.put(WSHandlerConstants.PW_CALLBACK_CLASS, ClientCallbackHandler.class.getName()); outProps.put(WSHandlerConstants.SIG_PROP_FILE, "client_sign.properties");
Whereas, Axis2 has an additional layer on top WSS4J called Rampart, Rampart has the notion of Outflow and Inflow security where Rampart handlers perform operations like Sign/Verify, Encrypt/Decrypt and so on. These are configured in XML as opposed to being coded:
<parameter name="InflowSecurity"> <action> <items>Timestamp Signature Encrypt</items>
The other thing that Rampart is the ability to hook into WS-SecurityPolicy as the great security architect Bill Gates says: "security should depend on policy not topology.", and WS-Trust so now you can build out an Security Token Server (STS) in Rampart. How you can sell/buy/run an ESB with out a STS is a continuing mystery to me - yes ESB vendors that is directed at you.
Anyhow, it looks to me that the Apache community has now produced not one but two ESBs that have potentially far more advanced security functionality than what is generally available in the ESB product categories.
By way of contrast - until the day I die, I will never understand this statement from our friends at IBM regarding ESB security:
“From the product design point of view, WebSphere Message Broker as an ESB is not the right place to implement WS-Security functionality. However, WebSphere Message Broker definitely is able to deliver the SOAP message with security credentials to its destination”
Great. We can deliver the message. We don't know who sent it, we cannot tell you if its been tampered with, but we won't lose it. What's interesting of course is that IBM sells another ESB Datapower that like its XML Security Gateway compadres is perfectly capable of
1. Delivering the message
2. Performing basic security services like authN, authZ, and so on
You can certainly complement WMB with Datapower or other XML Secrity Gateway and I know that is something that IBM pitches in its designs, but there is a big difference between realizing you have to complement and saying its not the right place at all. The graphic below shows possible options of implementing security in an ESB.
Of course there is a fourth approach which is you have security on the ESB and a XSG adapter, and this is often the best approach. I will have more to say on ESB security shortly, but in the meantime, should we really be worried about delivering things that we cannot verify? It seems to me that this approach leads to a highly reliable Sgt Schultz-style "I know nothing, I see nothing" implementation.

In the meantime, big ups to the Apache community for putting some hooks into interesting security primitives that facilitate building out much more advanced security architectures.
Its obvious that in most organizations, the major hurdle facing security in general and software security in particular is a people/culture problem not a technical problem. Software security is the canonical Texas Leaguer (a catchable pop fly that drops between the outfielder and the infielder).
One day in 1962, New York Mets centerfielder Richie Ashburn learned to scream "Yo La Tengo!" ("I got it" in Spanish) in order to prevent collisions with Venezuelan-born shortstop Elio Chacon. During a game a few days later, Ashburn exclaimed "Yo La Tengo!" - and was promptly hammered by an English-speaking teammate - rightfielder Frank Thomas.[Brooklyn-raised rocker Ira Kaplan loved the Mets so much that in 1984 he named his new band... Yo La Tengo.] Source: Anecdotage
We will see if the kids raised in the 21st century even call things Texas Leaguers any more, maybe they will just say "well you know it sort of a software security type problem...coulda been fixed but no one really owned it" The parallels of communicating in multiple languages and concerns is pretty obvious not just within development, operations, and security; but also across technical tribes - Unix, Mainframe, Java, .Net and so on.
The issue we have is that developers don't know enough about security, and security people don't know enough about software development. Until one side (or..gasp...both!) steps up and learns about the other discipline, this issue will remain.
I am speaking on May 14 at the Secure360 conference here in MN on Building a Security Architecture Blueprint, this is based on the Security Architecture Blueprint document that I published last year.
Building a Security Architecture Blueprint - A Strategic Approach to Enterprise SecurityInformation is a strategic asset, yet the practice of information security in firms is a patchwork of one off tactical solutions, that lacks a cohesive, rational framework. The purpose of the security architecture blueprint is to bring focus to the key areas of concern for the enterprise, highlighting decision criteria and context for each domain. Since security is a system property it can be difficult for Enterprise Security groups to separate the disparate concerns that exist at different system layers and to understand their role in the system as a whole. This blueprint provides a framework for understanding disparate design and process considerations; to organize architecture and actions toward improving enterprise security.
I am speaking at Ping's SSO Summit in Keystone, CO July 23-25. Agenda not published yet, my talk is called "Web Services Single Sign-On: There and Back Again", we'll look at everything that happens to identity as it traverses from the web front end through the middlleware to the resources and back.
I will also do a public version of SOA, Web Services and XML Security training at Usenix Security conference in San Jose July 29
This is a pretty funny list of three things to look in online banking, they are 1) dual presence (virtual and physical), 2) check in with credit unions, and 3) free checking. All worthy concerns to be sure.
I was a little surprised that they did not even mention anything about fraud/theft policies. Lots of banks work on security to get to anywhere from a low to medium level assurance, but what happens if and when they screw up? From a policy point of view - do their lapses and problems become your problems? A lot of times it does, and so it makes sense for consumers to know to choose banks that own some responsibility when assets are compromised.