According to the UK IT Governance blog, 148 million records were breached in December 2020!
As stories of data breaches hit the news each day, many companies are trying to patch the security of their systems as quickly as possible.
That's a start, but it's not enough. Security is not a one-time task. It has to be built into your development process, not added on as an after-thought.
A South African analogy
Think about system security the way you think about the security of your vehicle.
If you own a car, you don't want someone to hijack it, steal it or break into it.
To reduce the chance of such an unpleasant event, you have to take many steps. You might install a tracking device. You only need to do that once - but you do need to regularly test that the device is working. You should park your car in a secure garage at home. And you should be careful where you park the car when you go out. And you shouldn't drive around with handbags and backpacks visible on the seat. And, of course, you must remember to lock your car every time you leave it.
After a while, some of this becomes ingrained. You don't have to think about locking your doors, because it's become a habit. But then something will happen that reminds you to keep alert, or to rethink your behaviour.
It's never to early to start
Security is like usability and maintainability. The earlier you include it, the better the results will be.
Security starts as early as planning, and carries on through the entire process and beyond into maintenance. That's right - security should be built into your system development life cycle (SDLC). Regardless of what methodology you use, you need to embed security tasks into that process.
Of course, security must be part of the actual coding process. Include it in your design and in your code, and discuss it in your code reviews. (Code reviews? What code reviews?) And it should be part of your system testing before deployment.
A while back I asked this question: When do you know if something went wrong?. That's why security also needs to be part of an ongoing monitoring process after your system is deployed.
It starts with awareness
I haven't focused on any technical details this week. Instead, I want you to realise that security must be an intrinsic part of your development approach. Start thinking about all the ways security can be included in your process. We'll look at this in more detail in the next blog posts.
Read the next blog post in this series: Building better security - Part 2: Secure analysis.