Time for something a little more intellectual than usual. Here's a list of Do's and Don'ts when it comes to Security Architecture. Purely personal opinion. Feel free to argue. Feel free to agree. Feel free to ignore.
Do collect all of your security requirements from your business stakeholders, your regulatory environment, your wider enterprise and industry standards
Don't present me with an endless list of requirements saying the same thing but in slightly different ways. Consolidate your requirements set but maintain traceability by stating where your consolidated requirements originated
Do obtain sign-off from the relevant business stakeholders that the requirements are correct
Don't tell me that the Head of Security has approved the requirements and so we're good to go...
Do perform a comprehensive risk assessment of the system/service in question
Don't come back with a set of risks so abstract as to be useless - "An attacker may gain unauthorised access to my data" - well yes, but what's the business impact? What's the data? Who is the attacker? And are you talking physical or logical access? And are there any relevant attack vectors available to the threat actors you're worried about?
Do obtain business sign-off that the risk assessment is valid and caters for the risks that they care about
Don't tell me that the Head of Security has approved the risk assessment and so we're good to go...
Do define a set of security services based on your requirements and your risk assessment
Don't give me any services that cannot be traced back to a requirement or a risk. We're not doing this for the sake of it... It may be 'best practice' but do you need 'best practice' or is what you have good enough?
Do consider how your security services interact and how they are used by the relevant actors
Don't get bogged down with fully elaborating a security architecture - mental masturbation may be fun, but it's not productive. Do what you need to do to validate that your architecture is appropriate and is as complete as it needs to be.
Do consider any wider enterprise architectures that you are operating within. Your work may just be a view on a wider architecture
Don't simply assume re-use of existing services defined in a wider architecture without validating that they meet your requirements and are available for your use
Do tell other people about your work - an architecture is worthless unless it's used to influence design, build and run. Don't lock yourself away in an ivory tower and then complain that you're being ignored.
Don't exaggerate the importance of your work - architecture is a tool, sometimes a piece of art as well, but most importantly a tool.
Do remember that you're working in the real world. Whatever you're working on most likely has to be deliverable and affordable.
Don't be precious. This is just a general comment :-).
Well, that's my quick brain dump of do's and don'ts typed up as I sit here on a train heading home. I've probably missed lots of really important stuff - I may even have got some stuff wrong. In your opinion. Let me know.
Thursday, 18 March 2010
Friday, 12 March 2010
Web-cast musings
Was it great? No.
Was it utterly cringe inducing? No.
Better than expected? Probably.
What am I wittering on about? I did my second BrightTALK web-cast yesterday which was all about trying to show how cloud security need not sit (and indeed should not) apart from wider enterprise security frameworks. Given the topic I was expecting half of my audience to 'get it' and the other half to absolutely hate it; as it turned out the feedback was mostly positive albeit there was one member of the audience who only gave the presentation 1 star out of 5. But as I say, I was probably expecting more mixed ratings than I received and a number of 5 star ratings means it's currently standing at a 4.2/5 rating - which I'd certainly have taken before the gig! Main lesson for me is to try and not fit a 60 minute presentation into 40 minutes as I was aware that I was rushing through the content...
The really nice thing about BrightTALK is the ability to ask the audience to vote on questions of your choice. One of my questions gave a really interesting outcome - the question was around which service model the audience viewed as the most complex to secure. Both IaaS and SaaS scored 44% with PaaS only scoring 12%. I found this particularly interesting being as I was about to go on and say how I felt that PaaS was actually the most complex model to secure! Perhaps I should have run the vote again after the webcast... Now, I believe the low score for PaaS is probably because it's the model that's the least well understood - it's not as straightforward to understand as either IaaS or SaaS - rather than my audience believing it to be intrinsically more secure. But I could be wrong. Any comments out there? Do we need to expand more on what PaaS actually is?
Was it utterly cringe inducing? No.
Better than expected? Probably.
What am I wittering on about? I did my second BrightTALK web-cast yesterday which was all about trying to show how cloud security need not sit (and indeed should not) apart from wider enterprise security frameworks. Given the topic I was expecting half of my audience to 'get it' and the other half to absolutely hate it; as it turned out the feedback was mostly positive albeit there was one member of the audience who only gave the presentation 1 star out of 5. But as I say, I was probably expecting more mixed ratings than I received and a number of 5 star ratings means it's currently standing at a 4.2/5 rating - which I'd certainly have taken before the gig! Main lesson for me is to try and not fit a 60 minute presentation into 40 minutes as I was aware that I was rushing through the content...
The really nice thing about BrightTALK is the ability to ask the audience to vote on questions of your choice. One of my questions gave a really interesting outcome - the question was around which service model the audience viewed as the most complex to secure. Both IaaS and SaaS scored 44% with PaaS only scoring 12%. I found this particularly interesting being as I was about to go on and say how I felt that PaaS was actually the most complex model to secure! Perhaps I should have run the vote again after the webcast... Now, I believe the low score for PaaS is probably because it's the model that's the least well understood - it's not as straightforward to understand as either IaaS or SaaS - rather than my audience believing it to be intrinsically more secure. But I could be wrong. Any comments out there? Do we need to expand more on what PaaS actually is?
Subscribe to:
Posts (Atom)
