Guides
The truth shall set you free
I’ve worked in technology a long time now (relatively for me). It’s now over 20 years professionally and when I was a kid, I used to remove malware from small business’s etc. I’ve travelled to some funky places and done some cool things, but I learn new things every day. I do however come across some repeating patterns in my adventures as a consultant. There is a hidden truth that many are scared to admit…
Most organisations are not very good at service design, let alone secure service design!
Ok so there it is, I hope that this blog doesn’t age very well, but I’m 20 years in and I chat with my dad about his past life in the corporate world and we both see the same things being repeated. So, what can we do about it? Well sharing is caring, so here’s some things to think about when planning and designing a new service. I’m going to focus on the technology and security aspects, clearly, I am not saying ignore the business and value alignment but for the purposes of this post I’m assuming that the functional service capabilities and alignment are in effect. I’m also assuming that business case is solid because you know, without £ it’s a bit hard to create an operate a service (that’s a whole new post!).
Simplicity is key so let’s make this simple
Ok I could probably talk/type for hours about different service considerations and I could go into details about widgets and gizmo’s including about protocols etc. but I don’t think that’s where I want to go. For this I’m going to look at a capabilities and gap analysis style approach.
| Capability Area | Design Considerations |
| Asset & Configuration Management | How do we manage the assets both from a financial perspective but also from a systems perspective?How do we manage configurations? |
| Identity and Access Management | How will users be authorised?How can we have secure authentication?How can we ensure communications channels are secure (e.g., TLS)?
How can we ensure people are who they say they are? How do we implement a least privilege access position? How do we prevent people from exploiting common weaknesses? (e.g. Brute Force, Credential Stuffing, Dictionary Attacks, Pass the Hash etc.) How do we monitor this? (See security monitoring) How are we storing and managing credential access? |
| Secure Configuration | What vendor recommendations are there for hardened configurations?How will we manage these?How do we ensure these are implemented?
How we do measure and manage compliance with these configuration baselines? How will be protect from known malware? How will we enable response in the event an incident occurs? How will protect the service from network based threats? |
| Secure Operations | How do we ensure are staff operate securely?How do we ensure we can train our staff to ensure they have the required skills? |
| Change Management | Have we defined the demarcation between Administration and Changes?How do we manage change?What are the processes and procedures for changing the system? |
| Proactive Security Monitoring | How do we monitor for authentication events?How do we detect anomalies?How do we monitor all the interfaces?
Do we need to monitor for bulk data access? Do we need to monitor for sensitive data access? Do you keep an audit of security events? How do you ensure that audit log is immutable? |
| Security Testing | How do we test the security controls?How do we test the security controls after a major change?How often do we test the security controls? |
| Incident Response | How do we respond when there is a breach?Do we have the right tooling?Do we have the right skills?
Have we developed a response training plan specific for this service? |
| Vulnerability Management | How do we monitor and manage vulnerabilities and their remediations?How often do we do this? |
| Threat Intelligence | How are we made aware there are updates and security patches?How do we gain awareness of external threats related to the service? |
| Patching | How do we patch and maintain both functional and security-based patches for all components in the service? |
| Third Party Support | Are there any third parties involved in the support and operations of the service?How do we facilitate communications?How do we escalate if required? |
| Third Party Assurance | How do we gain assurance that the third party is operating securely?How do we gain assurance that the third party is operating in line with the specifications? |
| Availability & Recovery | How do we provide a highly available solution?How does routing maintenance and patching fit into the availability position?How do we recover in a minor scenario?
How do we recover the service if there is total loss? |
| Data Privacy | Are there any data privacy considerations for the system? |
| Legal Requirements | Are there any legal considerations for the system? |
| Policies, Processes and Procedures | Do we have relevant detailed policies, processes, procedures, and configurations documented?Where are these stored?Who can access these?
How are these available in the event of a disaster? |
| Documentation Repository | Where will all relevant system documents be stored?How will they be managed?How will they be secured? |
| Service Level Agreements | Are there any internal SLAs that must be adhered to?Are there any contractual agreements that must be adhered to? |
| Support and Operations | Who is contacted when there is an issue?Who is contacted when a change is required?How do we handle feature requests? |
As you can imagine this is hardly an exhaustive list. It should however get you to start thinking about service design and security.
Post Design – Understanding our gaps
Now that we have an idea around the capabilities, we want to consider we need to think about how this works in a design review but also when we are looking at an existing service.
| Capability | Current State | Future State Aim | Gaps | Constraints (blank on purpose) |
| Asset & Configuration Management | 1 | 3 | 2 | |
| Identity and Access Management | 2 | 3 | 1 | |
| Secure Configuration | 1 | 3 | 2 | |
| Secure Operations | 2 | 3 | 1 | |
| Change Management | 2 | 3 | 1 | |
| Proactive Security Monitoring | 1 | 3 | 2 | |
| Security Testing | 1 | 3 | 2 | |
| Incident Response | 1 | 3 | 2 | |
| Vulnerability Management | 1 | 3 | 2 | |
| Threat Intelligence | 1 | 3 | 2 | |
| Patching | 1 | 3 | 2 | |
| Third Party Support | 1 | 3 | 2 | |
| Third Party Assurance | 1 | 3 | 2 | |
| Availability & Recovery | 1 | 3 | 2 | |
| Data Privacy | 1 | 3 | 2 | |
| Legal Requirements | 1 | 3 | 2 | |
| Policies, Processes and Procedures | 1 | 3 | 2 | |
| Documentation Repository | 1 | 3 | 2 | |
| Service Level Agreements | 1 | 3 | 2 | |
| Support and Operations | 1 | 3 | 2 |
As you can tell, I’m modelling this off a real-world scenario. So here we have identified a range of gaps.
The journey isn’t over. After identifying gaps, we need to understand their cost, impact, timescales, resources, dependencies, and benefits. By understanding these we are then going to be able to prioritise design changes or remedial efforts. One thing I must made note of, there are almost always constraints. Be sure to identify, understand and socialise the constraints. It’s important that the stakeholders are aware and that these constraints can be managed. I’ve left a column in the gap analysis so that people don’t forget.
Putting this all together
Now you have to remember that when either designing or reviewing a system you need to do this from a range of viewpoints so that you can develop different views. Also just highlighting gaps doesn’t provide all the answers. You need to work out solutions for these.
This is just a taster of things to consider when designing ore reviewing a system. Computer systems are complicated, event the simple ones, by using a method you can ensure you cover your bases, you understand the strengths, weaknesses, gaps and that you can work with the business to achieve the business requirements whilst also ensuring the design follows good practises.
Hopefully this taster is helpful not only from a design perspective but also from a review perspective. Remember a design three years ago might not meet the current state business and customer demands.
