2012-01-02 23:28:32 by chort
Recently I was asked for some pointers on creating a security roadmap. Since there's no one-size-fits-all strategy for which programs or technologies to implement, this is a tough question to answer. After thinking about it for a few minutes, I stepped back and put together this abstract, which is really what security boils down to after all. The rest is implementation details.
1.) Understand what it is that you do.
2.) No really, go back to step 1 until you REALLY UNDERSTAND. WHAT. DO. YOU. DO?
3.) With this deep understanding of your product/service/business unit/charity, outline what "expected" operations/results look like.
4.) Find a way to comprehensively measure whether you're actually operating as expected, all the way from start to finish.
5.) Have a procedure for how to detect and handle deviations from what is expected.
6.) When prioritizing where to invest in detecting or addressing problems, consider whether the project you're undertaking really has an relevance to step 1. If it doesn't, stop. You're wasting everyone's time.
7.) Go back to step 1, because you probably don't understand everything yet.
Over-simplified? Sure. Idealized? Probably. My point here is that anything not related to the essence of your organization/widget is likely a distraction. The other point is that you need to understand your organization and process better than anyone else. If you don't know how it works, you won't know how it can be broken, or what it even looks like when it's broken! If you don't know what broken looks like, how can you detect anyone who's breaking it? If you don't know how it can be broken, what use is it to buy lots of expensive technology to protect it? Measure twice, cut once.
- Comments (0)