Good Morning:
When was the last time you used a pay phone? For me it was a LONG time ago. I'm not sure why I thought about that, but sometimes entire industries just go away and we hardly notice. Pay phones were a very big business for the phone companies many years ago. I remember having my trusty phone card always by my side and finding those germ-ridden phone boxes wherever I could to check in.

Yes, this was before cell phones became ubiquitous and Blackberry's made 24 hour connectivity not only possible, but connected. This is why I always tell everyone to question everything. I'm sure the phone executives didn't figure their cash cow pay phone business would just go away. Even early in the cell phone revolution. I still used my calling card in hotels because the cell phone was too expensive to use all the time. Now, not so much.

So what can kill your business? What will you do if your main cash cow just goes away? If you work for a big business, these questions may not be that relevant (since I doubt a company like GE is going away, even if a portion of their businesses), but if you work for a small business - it certainly is relevant. I see this every day. Companies that were great businesses are rendered obsolete. And the businesspeople either adapt or they die.

Darwin would be proud. He was right. Have a great day.

Incite #7: The SDLC is your friend

As innovation in web application scanners is crushed by consolidation and web application firewalls still can’t find its sea legs, security professionals finally get religion about building secure applications, largely to avoid the PCI stick in the eye and embracing the reality that applications remain the path of least resistance. A long, hard cultural struggle ensues between security and software development personnel, but by focusing on building the most critical applications securely, the tide turns regarding the secure systems development lifecycle (SDLC).

Read the original Days of Incite post on this topic.

6-month grade: C

I curse the PCI 6.6 clarification. Ugh. It was that one little clause of either WAF or code reviews/SDLC to be compliant with 6.6 that torpedoed this Incite. Fact is, I've written a lot about the fact that most organizations will opt for the path of least resistance, and that usually means a box - as opposed to a process change. And a WAF is a box, and an SDLC is a process change. Guess which one wins, when deemed reasonably equal in the eyes of the assessor?

Now has their been a lot of innovation in the WAF space? Not really. But who cares. It's the path of least resistance for many trying to outrun the specter of PCI - so it's not only have WAFs found their sea legs, but you are seeing integration with web app scanning and other parts of the eco-system. By the way, if being wrong about an Incite means things are moving forward - then I'm cool with it.

But what about secure development practices? What about SDLC and code reviews and the like? Yep, they are still important and I think that implementing these concepts now will pay dividends for years down the road. And I also know it's hard and that many dev teams will be resistant to changing the way they do things. All I can say is to keep fighting the good fight and focus. 

One approach is to build up a grass roots effort by focusing on those apps that directly handle critical data. You aren't going to totally and fundamentally change things overnight. Nor should you. Some apps don't need to be overhauled, since they are either not exposed or they don't handle sensitive data. But for those that do, keep banging away. Yes you get a headache, and probably a callas on your forehead. 

If it was easy, everyone would be doing it.

Photo credit: "Path of Least Resistance" by kisses are a better fate than wisdom

2007 Incite: The Information Strikes Back
2007 finally brings acknowledgement that data/information security is different than protecting the network and servers. Yet, there is a major skills shortage in folks that understand how to protect applications and databases, resulting in accelerating interest in application and database security product offerings. But history will repeat itself, as a “fool with a tool” is still a fool, which doesn’t help customers solve any problems.

2008 Incite: The SDLC is your friend
As innovation in web application scanners is crushed by consolidation and web application firewalls still can’t find its sea legs, security professionals finally get religion about building secure applications, largely to avoid the PCI stick in the eye and embracing the reality that applications remain the path of least resistance. A long, hard cultural struggle ensues between security and software development personnel, but by focusing on building the most critical applications securely, the tide turns regarding the secure systems development lifecycle (SDLC).

Like yesterday’s piece on laptop encryption, I decided to split the 2007 information security Incite in 2008. Why? Because starting to implement a secure software development lifecycle (SDLC) is a key imperative this year. No you can’t wait until next year or the year after that. Software projects take years to go from idea through deployment to maintenance. Sure there are many iterations along the way, but if a project starts in 2008 and isn’t built thinking about security from the get-go, it’s not going to happen later.

I’m not going to go through the numbers of why it’s important to fix software defects early in the process. That is obvious or at least it should be. You want to eliminate issues prior to software being deployed. Bokay?

Here’s the rub. Organizationally, it’s hard to embrace secure coding standards. You need a seriously high level mandate to get everyone on board, and those take some time. Yesterday on Microsoft’s SDL blog, Michael Howard, details how Microsoft embraced their SDL. Basically they did it because Bill Gates told them to. They had no other choice. Unfortunately sometimes that’s what it takes to get the behavior changes that are required.

There are other reasons why the SDL needs to be a short-term imperative. It may be the first situation where security leadership influences other parts of IT and the business to think about security – before they have to. Remember, being a senior security professional requires sales and persuasion skills. Yes, these are more valuable than technical chops moving forward.

As I mentioned, it’s a long tough slog to get the developers to do a threat model when they are architecting the application. It’s hard to get Q/A to add more security tests to their harness because they are already behind since they got the code late. It’s hard to get them to hold up a release, which is already late, because there are serious security holes. Yes, it’s hard.

So how do you increment to get there, knowing that true adoption of the SDLC will take years? Basically you need to attack the issues on multiple fronts. You’ve got to make the investment in the process (SDLC), but you are also well suited to start thinking about how tools can supplement your efforts to amend the process.

Neither web application scanners nor web app firewalls ever really hit the big time. They remain interesting niche markets, but that’s far from what is required to solve the problem. Let’s hit the scanners first. Basically these tools tell you (at a high level) where the holes are in your applications. Actually, to be more correct, they will find SOME of the holes.

Web app scanners cannot find logic flaws in your applications. They have trouble detecting cross-site request forgery. You still need humans to do that. So running the systematic application penetration test is critical to uncovering those issues the technology doesn’t catch. The fact is the tools only go so far and we still need skilled humans to do a comprehensive analysis of an application.

Yet, running a current generation scanner is better than not running one at all. Two of the biggest players in that space were Watchfire and SPI Dynamics. Both were acquired last year by the development tools divisions of IBM and HP, respectively. There is a real risk that innovation slows for both of these companies, since the scanner business is hardly adjacent to development tools.

On the web app firewall front, these devices just never got going. And now you have new entrants (like Palo Alto Networks) and the existing firewall folks claiming to do more sophisticated application-level firewall functions. There are some protocols and attack vectors that web app firewalls handle, that the other devices can’t. Does that mean you need it? As usual, it depends on what you are trying to protect. If it’s that important, then the answer may be yes. But the market has spoken thus far, and web app firewalls are being voted off the island.

I want to wrap up with a little career advice. I get asked frequently where practitioners should focus their efforts and how they can maximize their opportunities and status within their organization. I tell them to learn how to break and protect applications. There is a major skills shortage in dealing with application security, so if you are looking to become more relevant – that’s where to supplement your skills.

Photo credit: freshelectrons