[soapbox]
Within a week or two after every high profile data breach, we get naysayers and Tuesday Morning Quarterbacks playing the “If they only did X …” game. You know – the game where they are always right in hindsight. I am a bit surprised Pescatore jumped on that bandwagon in Simple Math: It Always Costs Less to Avoid a Breach Than to Suffer One, but he did.
Now that we have laid out the Agile process it’s time to discuss where different types of security testing fits within it. Your challenge is not just to figure out what testing you need to identify code issues, but also to smoothly fit tests into the framework to help speed testing. You will incorporate multiple testing techniques into the the process, with each tool or technique focused on finding slightly different issues. Developers are clever, so development teams find ways to circumvent…
Last night I spent four hours without my iPhone. Four conscious hours, to be specific. It was wonderful.
I realize that may sound strange, but I bet the majority of you reading this nearly always have a phone within hearing range, if not actively grasped in your hand or stuffed in a pocket where you obsessively check it every now and then, when the slightest breeze triggers the vibration nerves in your upper thigh.
The NFL has had a tough week. The Ray Rice stuff I mentioned last week. And uber-running-back Adrian Peterson deactivated on Sunday, due to a child abuse indictment. The stories are terrible, especially given that NFL players are explosive athletes and trained in violence. No kid or spouse has a chance in the face of an angry NFL player. And no, I’m not going to anywhere near Floyd Mayweather on this topic.
This is the fourth installment of our Secure Agile Development research. Today’s post discusses one of the toughest parts of bringing security into an Agile program; process modification. The common waterfall development process has cleanly delineated phases, each of which provides an opportunity for security integration, and each security activity must be completed before moving on to the next phase. Agile includes whatever work gets done in the sprint – it does not bend to security so you…
After a short break, the boys are back and here to talk about Apple. No, not the new wrist-mounted toy, but the first mobile payment system you might actually use. Or so says Rich’s Macworld editor, based on his article title.
Once again Wendy kills it with How to Help, saying things many of us probably think. Daily. It can get frustrating when all you hear is one person after another bitching about what’s wrong with security. And as she correctly points out, there are tools aplenty to tell you exactly how much work you have to do. But that doesn’t really help.
You read the series, now it’s time to download the collected works.
Okay, maybe you read the series of blog posts. And by “collected works” I mean “white paper”, but you get the idea.
One day will be a business school case study how NFC went from handset (started with Nokia) to telcos to banks (HCE) and then to platforms
In the next couple posts we will break down our advice for adding security into Agile development. We will do this by considering the involved people, necessary processes, and technical integrations. Today’s post focuses on helping security professionals, first by outlining how Agile development works, and then by providing recommendation for how to work with development teams.