What is it and why should I care?
This is a bit of a follow-up to my last post with a bit of a different viewpoint. In that post, I specifically looked at code reuse from the perspective of creating an internal framework to centralize code related to security functionality.
This week, I want to consider security a little more generally. Code is not the only thing produced by “security” mechanisms. There are processes, documentation, code, people, etc. Re-inventing each of those per-application or even per-organization is a huge waste of time and money. In addition, for the same reasons that I mentioned regarding code reuse, each individual incarnation (say, by a given company) of a given mechanism is likely to be of a lower quality than if multiple organizations pooled their knowledge and/or resources to produce a common template.
By looking for areas of commonality and building tools, processes and documentation to meet those needs, everyone benefits.
What should I do about it?
Essentially, don’t reinvent the wheel.
– If you’re looking to teach your developers (and/or yourself) about how to prevent XSS, don’t start writing your own doc, look at resources that already exist like the OWASP cheat sheets. The OWASP material is really good on XSS. In some other areas, OWASP’s documentation is weak, but you can often find other good resources, and take a best-of-breed approach.
– If you’re building out a plan for how to add security to the SDLC in your organization, don’t try to roll your own. At least evaluate existing models and see if they fit your needs. Chances are they cover most if not all of what you need. Additionally, they probably have thought of things you haven’t considered yet, particularly if it’s an established methodology.
– If you’re considering which, of all the important security issues, you should cover first in your application, look at existing analysis. Consider breach reports and what’s being exploited. Use the data that’s available, and don’t just start with what you *think* is true. Measurement of the data will often quickly change your opinion.
Here are a few concrete steps to prepare you for working in this way:
1. Assume you’re not the only smart person around
Let’s go out on a limb and assume there may have been others that have come before you that have had an intelligent thought or two. It’s OK (excepting certain license/copyright issues) to reuse what others have done. It’s OK if it’s not all done in-house. Reuse what you can from others, and then use your time to make improvements instead of starting from scratch.
2. Read, read, read
In order to know what others have done, it’s really beneficial to be knowledgeable about what’s current in your field. This obviously applies to many fields, but technology and security change quickly, so you must stay current.
3. When you have a need, do the appropriate research
When you have a specific need, you should have a general idea of what’s available (if you followed step 2 above) to meet that need. However, you’ll probably still need to do a bit of directed research to get the detailed information and see what will fill the current requirement you have.
4. Tailor the mechanism to your environment
While it’s great that there is a lot available for reuse if you look for it, there are often good reasons to tailor the solution to your specific environment. Often times, you may need to change terminology, or you might have a simpler or more complex model to work from. You might have different threats, or you may have solutions that prevent entire classes of issues across the board. Tailoring a solution makes it specific to your organization and can add a lot of value.
5. Fix things that are broken – sometimes the wheel IS actually square
Sometimes what’s out there is bad … sometimes it’s really bad. When that’s the case, you’ll have to start from scratch. You may be able to glean some things from what’s out there, but you may end up needing to do some or all of the work. This is obviously not the greatest option for most situations, but is sometimes necessary. If this happens, try to build something that is as reusable as possible – you never know how others might use your work.
6. Contribute back to the community
Whether you have something you tailored, or if you had to build something from scratch, you can often help others by sharing your work with the community. Obviously, this is not always possible, but when it is, it can be a boon to you and the community. If you put something out that gets used, then you could be a) boosting your career prospects, b) creating a standard tool/process/document, and c) helping others by sharing your insights.
7. Build a custom holistic plan
The real benefit to an organization of the “thinking” of its’ security people is that they can evaluate the environment that the organization operates in, and build a working model that custom-fits the organization using best-of-breed individual solutions. If you don’t need something, throw it out. If you have a gap, fill it. That’s tremendous value-add to the organization. By knowing both the general landscape as well as your specific environment, you can build a tailor-made plan that evolves over time and is best suited to secure your organization. This plan should be holistic in nature, and will certainly fill out over time, but you should begin your planning with your end-goal in mind.
In conclusion, there are lots of existing resources at the disposal of the security practitioner. If there’s no resource to meet your specific need, you can often tailor something that already exists, or in some cases, you may have to build one from scratch. Either way, sharing your work with the community can help us all move forward.