Skip to main content


Here's a rough outline of the sort of stuff to consider around nonfunctional security requirements.

Foremost is identifying and classifying who is using the system in the first place from a functional perspective. These actors will likely fall out directly from the use cases and other requirements modelling exercises so you'll have end users, business users, administrators, editors, whatever... These will probably turn into roles in the security model of the system. ok, cool.

So assuming everyone stays nice and friendly, never lies, and obeys the rules you lay down then you can probably go home now - job done! Erm, but they don't and you need to assume that every actor; human or system, is a liar and a cheat, wanting to steal your data, corrupt your system, bend the rules in their favour and so on. So a short list as a starter for ten of topics which need to be considered - let me know what more needs to be added:

  1. Authentication and authorisation - How user identities are authenticated and authorised - who are they and what can they do?

  2. Identity and access management - How identities and access control is managed. From password reset policies to identity providers.

  3. Auditing and logging - The recording of events for analysis and accountability; including for non-repudiation purposes.

  4. Encryption - What do you encrypt and how do you do it? Much more than just SSL - which is a good start over the public network - you've got to worry about the insiders as well and; fearing the worst, what if your defences are breached and data is stolen? Using weak cyphers and home-grown algorithms is nearly as bad as storing sensitive data in plain text.

  5. Security zones and network zones - Creating distinct zones to protect critical resources, limiting access accordingly and auditing every gnats fart that occurs in your data-centre. Employing network appliances such as firewalls, reverse proxies and network intrusion detection systems accordingly.

  6. Secure development practices - From preventing code injection attacks to avoiding buffer overflow problems and employing defensive programming techniques. The Open Web Application Security Project (OWASP) has excellent resources on everything relating to software security.

  7. Denial of Service - How to avoid and deal with DDoS attacks (Distributed Denial of Service attack)? In the 21st century public services and businesses are utterly dependent on the net and cyberterrorism will become increasingly prevalent as the first frontier of attack.


Popular posts from this blog

An Observation

Much has changed in the past few years, hell, much has changed in the past few weeks, but that’s another story... and I’ve found a little time on my hands in which to tidy things up. The world of non-functionals has never been so important and yet remains irritatingly ignored by so many - in particular by product owners who seem to think NFRs are nothing more than a tech concern. So if your fancy new product collapses when you get get too many users, is that ok? It’s fair that the engineering team should be asking “how many users are we going to get?”,   or “how many failures can we tolerate?” but the only person who can really answer those questions is the product owner.   The dumb answer to these sort of question is “lots!”, or “none!” because at that point you’ve given carte-blanche to the engineering team to over engineer... and that most likely means it’ll take a hell of a lot longer to deliver and/or cost a hell of a lot more to run. The dumb answer is also “only a couple” and “

Inter-microservice Integrity

A central issue in a microservices environment is how to maintain transactional integrity between services. The scenario is fairly simple. Service A performs some operation which persists data and at the same time raises an event or notifies service B of this action. There's a couple of failure scenarios that raise a problem. Firstly, service B could be unavailable. Does service A rollback or unpick the transaction? What if it's already been committed in A? Do you notify the service consumer of a failure and trigger what could be a cascading failure across the entire service network? Or do you accept long term inconsistency between A & B? Secondly, if service B is available but you don't commit in service A before raising the event then you've told B about something that's not committed... What happens if you then try to commit in A and find you can't? Do you now need to have compensating transactions to tell service B "oops, ignore that previous messag

Equifax Data Breach Due to Failure to Install Patches

"the Equifax data compromise was due to their failure to install the security updates provided in a timely manner." Source: MEDIA ALERT: The Apache Software Foundation Confirms Equifax Data Breach Due to Failure to Install Patches Provided for Apache® Struts™ Exploit : The Apache Software Foundation Blog As simple as that apparently. Keep up to date with patching.