Jim Manico has produced another great addition to his OWASP podcast canon, the latest discussion is with Richard Bejtlich. Jim is very good as an interviewer which means the questions are all meat and potatoes on in the trenches issues.
One of the main points that Richard makes that is lost on many security programs is how to take information security concerns and then communicate them to the business. How do you talk about security to people (i.e. business) that could care less about SQL injection. As James McGovern says, the business doesn't want a maturity model, they want working software.
Richard talks about extending the communication through using threats, and that this is a way to put a face on the problem. I have no doubt that this works well. The BBC show "Spooks" (called MI-5 in the US) is a pretty detailed (for a TV show) look at counter terrorism in the UK, they get into a lot of hidden assumptions we have about the intersection of security and privacy. One of the criticisms of the show is that it looks like all the problems are solved in one hour by the same three people. And this is one issue I have with using threats as the primary means for communicating security concerns to the business. I have no doubt its effective, and its for sure an important part of telling the story, but I think some aspects are not addressed if there's an overfocus on threats. Threats must be assumed but its resilience and survivability that matter in the end and that goes back to your company's mission.
I came up originally looking at security as something that we solve through equal parts access control, defensive coding, and crypto. Those are still the basic workhorses of most software security regimes, but there is a missing piece. For me, Richard's work going back Tao of Security Monitoring is the best distillation that made me realize that all of the above areas must be backstopped by a robust detection and response lifecycle, or what Richard calls "Building Visibility In"
So in terms of building visibility in, every process that we design/code for should have a "monitor first" mandate. We saw the lack of this just recently with the Chip and PIN fiasco. There are real challenges to getting the right amount of visibility in the app. Where you put the detection determines what you see. On the presentation layer it looks like raw HTTP, at the middle tier it looks more transaction-like and at the DAO layer you can observe the data operations. In the secure audit logging class I teach we go through each of these areas and its very interesting to see what you can see from these different angles, just like turning a Rubiks cube.
Jim and Richard explore a couple of other areas - issues around incidents/compliance for funding (for which I propose the need for a flat tax). Jim asks about how attackers have advantage, and Richard responds with his black hat budget, in other words what can the bad guys do with a fraction of your assets.
Jim asked Richard a question I sent in - "The trustworthiness of a digital asset is limited by the owner's capability to detect incidents compromising the integrity of that asset." Given that we don't have any high integrity database, identities or application servers - how do you detect a breach of integrity when there is no verifiable integrity in the system in the first place?"
Richard's response is that trustworthiness impossible inside an asset itself (agree)- for an asset to defend itself look outside of the asset. The network is a cheap way to watch. That logic makes perfect sense to me, but it still makes sense to push for more and better data out of the apps. There is a lot of context there about transactions, data, identity and so on that can be harvested.
I quite liked the final challenge that Richard threw down - enterprises need to focus on getting real data. How many of us have an accurate scoreboard based on real data?