But you know what? I think that my current depressed state has changed my way of thinking about security (or changing my way of thinking about security is making me depressed…). I agree with him that the source of the problems is bad security from the deep of the systems we rely on Today, bad (or no) security design in general. But I just think this is a problem we cannot solve. We can see the same issue on several other disciplines, old design and decisions being perpetuated in a way that causes issues to current stuff. However, revolutionary approaches are not (or are almost never) possible due to the way that economy and society works. The technology evolution is also so fast that it would require too many revolutionary processes to solve the recurrent problem of old decisions based on premises no longer valid causing problems to the current state. We simply cannot afford burning everything to ground and start fresh again. All these things are competing for resources and it would be naive to believe we could just choose to build everything with the perfect design.

Gunnar uses the example of the Chicago reconstruction after the great fire. I think it is a great example, but it doesn’t fit exactly his intention. It shows that once something out of your control happens and puts everything to the ground, you have the choice to start fresh and with a better design. Now, how many times have you got the opportunity to start something from scratch in IT? Hey, wouldn’t it be nice to build an OS with no backward compatibility concerns? Ask Microsoft if they don’t dream with that every night!

Gunnar is asking for something right that is just not practical. Maybe I’m being too cynic and conformist, and I believe we need people who push us to take those revolutionary roads, but when someone does that is usually the exception and not the norm. Those who are dealing with real life issues need to be pragmatic. Yes, we need to protect our straw houses.

What I think is more important from Gunnar’s post is this line:

“The boring stuff is what’s important”

That’s different from trying to re-design everything. There are lot’s of boring stuff that we need to do to protect the straw house My first and main example is access control. IMHO there isn’t anything more boring in Infosec than Access Control – access reviews, entitlement reporting, fire IDs, privileged accounts tracking, wow, those things kill me. But I must say that doing those things properly will probably reduce a lot more risk than buying the last pretty-pizza-box-with-blinking-lights. The problem will be finding smart people who enjoy that enough to that properly.

 Today’s biggest challenge in Information Security is to find smart people willing to work with boring stuff.

That’s my last line from my “back to blogging post”. Wow, I’ve just noticed how much I miss doing. Ok, I’m back

When the issue is on libraries, libraries that are used everywhere, this thing becomes a nightmare. You are now relying on the ability of all your software providers (COTS software and “tailored” stuff) to identify the usage of those libraries in their products, and also on the ability of your developers to do the same. Does your vulnerability management process includes a procedure to check with developers if they are using vulnerable libraries? Do you track libraries on those processes too? I haven’t seen that being done out there.

There are lots of file scanning technologies deployed everywhere. Antivirus, content discovery, DLP. Can we leverage those technologies to look for the presence of vulnerable libraries? I wonder if someone is already doing that…

event = tr’ || (select case
when substr(banner, 1, 1) = ‘A’ then ‘u’ else ‘X’ end from (select
banner from v$version where banner like ‘%Oracle%’)) || ‘e

Read the full story here.

Details about the webinar:

Middleware Security Holes You Need to Know About:  They Increase Risk of Breaches, and Will Make You Non-Compliant with PCI  

April 15th, at 12 Noon ET; 9 am PT

With T.Rob Wyatt of IBM

The Heartland Payments breach is another case where hackers were able to compromise the “soft center” inside the corporate network. One of the major security holes that remains unplugged in many organizations is middleware, especially middleware used for application-to-application and application-to-DB communication.

This webinar will feature the expertise of T-Rob Wyatt who is an IBM security consultant focusing on IBM Websphere MQ, which has been implemented by over 15000 enterprises around the world.  T-Rob will talk about some of the security problems he has found working with merchants, payment processors and other enterprises, most of which have been missed by PCI assessments, often because PCI QSAs are not familiar enough with MQ series and other middleware to evaluate the security of the configuration.

This webinar will be very valuable for merchants, banks, PCI assessors and anyone else who is not sure what middleware vulnerabilities they have and how to make the changes to eliminate them.

SPEAKER:  T-Rob Wyatt – Senior Managing Consultant, IBM

Topics to be discussed include:

** What are the major middleware vulnerabilities?
** What organizations still have these vulnerabilities?
** What is required to eliminate these vulnerabilities?
** What should organizations do near term to solve this problem?

Mike also mentioned, again, the need to REACT FASTER (have I said how nice his “Pragmatic CSO” stuff is?) and linked it to the application security world. As I’m working a lot with log management these days I noticed that I’m not seeing people talking about what to do with their Web and application server logs. A lot of attacks against web applications can be identified in the logs, and yet we don’t see people collecting and analyzing them. Is there anybody out there with good results on “web log” correlation? I’d like to see how evolved this is and how can it help as an early warning system for attacks against web applications.

“For good programmers, one of the best things about working for a startup is that there are few checks on releases. In true startups, there are no external checks at all. If you have an idea for a new feature in the morning, you can write it and push it to the production servers before lunch. And when you can do that, you have more ideas.

This didn’t merely make them less productive. It made them hate working for the acquirer.”

Assuming that writing secure code and the complete Secure Development Life Cycle can be described as “checks” and “controls”, it would be natural to assume that good programmers don’t want to work for companies with a SDLC in place. That is certainly an important thing to consider when considering a more secure approach to software development.

We know that a SDLC works for generating more secure code. But can we keep the good programmers while doing that? Can this issue be a problem big enough to make a company choose to not implement a SDLC?

• “User: This is an area I intend to talk about in much greater depth later on. Basically, right now we rely on static authentication (a single set of credentials to provide access) and I think we need to move more towards adaptive authentication (where we provide an authentication rating based on how strongly we trust that user at that time in that situation, and can thus then adjust the kinds of allowed transactions). This actually exists today- for example, my bank uses a username/password to let me in, but then requires an additional credential for transactions vs. basic access.
• Transaction: As with user, this is an area we’ve underexplored in traditional applications, but I think will be incredibly valuable in cloud services. We build something called adaptive authorization into our applications and enforce more controls around approving transactions. For example, if a user with a low authentication rating tries to transfer a large sum out of their bank account, a text message with a code will be send to their cell phone with a code. If they have a higher authentication rating, the value amount before that back channel is required goes up. We build policies on a transaction basis, linking in environmental, user, and situational measurements to approve or deny transactions. This is program logic, not something you can add on.”

I’ll keep out from this post the ideas about cloud computing, layers and the real meat of his post, but I want to stress how nice the adaptative authentication and authorization concepts are. Richard is right when he says that banks are already doing that, I remember including the concept in the online banking of a Bank I worked for almost 4 years ago. The thing, however, would be trying to bring that to other authentication and authorization actions that exist inside (and outside, in the cloud, whatever) the organization. It could be used to further protection on privileged IDs, to enforce higher controls over remote access from potentially malicious networks, specific time ranges, and a lot of other things that could be used to indicate a higher threat level. In fact, it could even be deployed by transparent proxies in front of the applications without a need to change code or hard to deploy integrations.

Definitely, something that should be better explored by security vendors.

He blogs about a series of things, but mostly on software development and security. His last post (VP, you need to develop something to link directly to an specific post!) about vulnerabilities related to debugging code is pretty interesting.

Welcome back, VP!

Read this, from Gunnar Peterson!