editione1.0.0
Updated October 9, 2023With security, as with most things, once our software has been delivered and we are happily serving our customers, our job has only just begun. Security is important for the life of the application or system, which (we hope) is for many years to come.
All internet-exposed systems are subject to security activity, and it’s important that you spend some time thinking about how you and your team will identify when such activities are taking place. The sooner you know, the sooner you and your team can respond and protect your systems and data from harm.
While we won’t cover how to set up monitoring and alerting systems in this book, we will give you some idea of the things to consider when doing this crucial work.
confusion Remember, these guidelines apply whether your team is responsible for monitoring and maintaining your software, or you have outsourced this to a support team. These requirements are either intended for you to follow or for you to communicate to your supplier as part of your expectations on them.
Monitoring is all about anomaly detection and correlation. The more data and events you log, the more you can correlate and use for anomaly detection. You can’t get back data if you didn’t log in the event of bad things happening.
Store logs away from your software and make them immutable. If there is an issue with your system, you want your logs to be safe from harm and stored away from the system they relate to. Keep them safe, keep them for a long time, and don’t let anyone edit them.
A log you don’t check can’t help you. It’s all very well to log everything and implement monitoring systems but if you and your team never check them, they are doing you no good. Make it easy to check your logs.
Embrace interrupt-driven response. Configure your monitoring system to alert you when unusual situations occur. This alert will draw your attention and prompt you to investigate. If you are hosting your logs in a cloud provider, check out their platform offerings in this space, as they may provide anomaly detection as part of their service.
Centralize your alerts. Many of us are guilty of filing emails and alerts into a folder and never checking them. Bring your alerts to a central location that your team can monitor together. This reduces the risk of missing something important.
Have a plan for when things go wrong. If you spot something suspicious or your team sees an alert that’s alarming, they should all know what to do. Define a plan for these situations and practice it. The more prepared you are for this sort of event, the easier it will be to get your business back on track if something goes wrong.
resourcesSecure software development is a big topic, and impossible to cover fully in one chapter. These resources are aimed at a technical audience, and will most likely suit people in engineering leadership roles:
Microsoft Secure Development Lifecycle, an open guide to Microsoft’s approach to secure development, featuring well-documented guidance on processes such as threat modeling.
Agile Application Security by Bell, Smith, Bird, and Brunton-Spall, a complete guide to weaving security through fast-paced software development life cycles.
The Open Web Application Security Project (OWASP), home of the de facto standard guide to common vulnerabilities, the OWASP Top 10, and hundreds of other resources including tools and frameworks. Looking to get started? Check out the Software Assurance Maturity Model (SAMM), the Application Security Verification Standard (ASVS), or any of their free-to-download ebooks.