Leading a security team

Today I want to start from this sentence written by Frederick P. Brooks, JR. The Mithical Man-Month:

Software systems are perhaps the most intricate and complex (in terms of number of distinct kinds of parts) of the things humanity makes

Being the most complex systems the man can build, software systems are addicted to numerous mistakes either conceptually either technicals. Each mistake hides a bug, and some specific bugs ( the one that could affect the normal security model of the designed system) could become a vulnerability. This is the “why” we still find and we will find vulnerabilities in softwares … This is the “why” we will need security experts to handle crisis generated by such a vulnerabilities. In this post I’d like to review some of the basic concepts of “team leadership processes” and apply them into red teaming. This is not going to be an exhaustive review of the most used leading concepts but rather a different point of view (from a security perspective) in classic team leadership patterns.

1. The craft of “securing”. Even if many people can argue that security is becoming a science, I do believe we still are in the “craft” time frame. We can’t say it is an Art, because we have methodologies, guideline, policies, and even designed patterns. We can’t say it’s science, since we can’t reproduce the same results (aka the same security level) in every environment. We still have no idea on how to measure “security”! So it is correct to call the “security discipline” a craft. If it is a craft we won’t be able to predict the precise cost of “securing” a system. We won’t be able to know how many ‘penetration testing hours’ are needed to secure a whole system, we need experience to be able to give an accurate estimation.
2. The joy of understanding. While Frederick P. Brooks in his famous book pointed out that the “craft of programming” gratifies developers because they are making things, we cannot say the same for security engineers. We had not the joy of making things.. Developers make things, we broke things for testing their security properties. So what is the spirit of a security engineer? The joy of understanding how things are done. A great security engineer is the one who loves to disassemble, to learn, to discover how other people did such a thing. The necessity in understanding, in learning, in disassembly things take the security engineer in a position to know what is strong and what is not. After some experience the security engineer is the one able to compare two different systems and to judge their models and their designs with respect to security features.
3. Good cooking takes time… Security process such as the penetration testing process needs time, it cannot be hurried without spoiling the result.
4. Partitioning a task among multiple engineers occasions extra communication effort, that it doesn’t come for free. Partitioning is often a great solution but is not always the best solution. Adding people at the end of a penetration testing process will take to this process much more time respect of having no additional engineers. If you are in rush don’t add more people. People need to be trained and they need communication with current engineers to catch up the whole contest before being able to produce actively to the process. Take people into penetration testing at the beginning of the process, never at the end of it, you will not finish the process on time.
5. The perfect team. A chief-security engineer, a surgical-team made from a small amount of talents offers a way to get the process integrity of few minds and the total productivity of many helpers, with radically reduced communication.
6. Find the most valuable vulnerability. Finding the most valuable vulnerability often correspond to attack the conceptual integrity of the system. Understand how the system works, and firstly focus on the conceptual integrity of the system and later on technical aspects.
7. Communication between team members. Definitely the most important task a team manager have to guarantee. Communication. Thanks to communication people have new ideas, find solutions and find the way after having lost it.
8. Organization and role definition. A good organization and a good role definition is fundamental to coordinate talents and often “big egos”.
9. Plan to throw one away. According to Frederick P. Brooks, JR. In The Mithical Man-Month, there is always a wrong way that eventually you and your team will take, you will, anyhow. Plan to throw it away, and start from the previous state. Don’t loose time in tying to recovery a test, don’t lose time to try to convert a specific designed tool to fit another bug, don’t try to reuse a reverse engineering status from the previous code revision. Find the power to admit the failure and start it again.
10. Documentation, documentation and… (Try to guess… ) documentation! Is your only true weapon to speed up the learning process and enable a fast context change. I know, when you reached a result, such as a tool for testing a specific system, a 0day or a new injection status you think to be wasting time writing documentation. But is not like that… And you know that. So remember each time you should write docs, that is almost valuable as the task you have just concluded.

If you have to manage a penetration testing group, I hope it might be helpful. Let me know, any comment is appreciated