What is it and why should I care?
With the current series coming to a close (wow, finally :>), I’m going to do a bit of wrap-up.
While all the posts in the series hopefully have something to offer, I’ve saved my 2 most oft-repeated pieces of advice for last. Actually, neither is specific to Java, security, or even technology. However, they are the two concepts I find myself sharing the most with others. I’m sure you will relate.
The first concept and focus of this post is … “Think”.
Sounds fairly simple and clear, but not done nearly enough. It’s not that people don’t assimilate information and spit out an answer – they do. The problem is that a) they often don’t consider all the variables and b) they don’t second guess the existing solution or consider if a better solution is even possible. I’m not suggesting that you have to re-think every decision you make, but if you’re making an impactful (time, money, people, etc.) decision, it’s worth your effort to consider the implications and make the best decision possible.
What should I do about it?
There’s a whole host of decisions that this can apply to. As a for instance, here are a few examples using other posts in this series:
- You need to build an application securely, so you create a threat model. Certainly feel free to reuse, but think about why those threat actors and attack vectors are there in the first place. Do they even apply to your application? Are there others that do apply that you’re missing?
- You are storing user passwords, and need to make sure you’re doing it securely. Well, don’t just grab the library someone used on another project (without a good reason). Think about the actual requirements you are trying to fulfill, and evaluate solutions based on that.
- You are tasked with architecting a reusable authentication and access control solution for your organization. Consider the requirements that you know of right now as well as those that are coming down the road (as best you can). Consider the needs of various stakeholders. Another organization’s solution may or may not be right for you.
- You perform a code review on an application that is using a new-fangled data storage and query solution. You’ve never seen it before, but it looks a lot like nosql. Consider the security issues related to nosql (authentication, access control, injection, data management, etc.) and extrapolate that these issues likely apply to the new solution. Also look for differences, and consider what issues might crop up because of the deltas.
I could make a really long list here, but I think the basic idea is clear. In order to be effective, you must give thought to why you are doing what you are doing. There’s a lot of security advice floating around (I gave a lot this year), some good and some bad. However, even the good advice must be tailored to your specific needs. Maybe a solution might apply for 99.5% of people out there, but your organization may not be one of them. That’s ok, but solving the problem for you means a) you don’t blindly accept the advice as law, and b) you know enough about your environment to decide what the correct solution is.
There are many problems that exist (and most that get solved) in security and elsewhere that are generally resolved by considering the problem and choosing a well-known solution from your toolbox. That’s logical because many of us encounter similar problems and come up with similar solutions, contributing to the communal mind (think OWASP documentation and projects).
However, there are some issues and problems that require a bit more work to solve. You start hearing things like “think outside the box”, be a “creative thinker”, and a whole host of other catchy phrases. The point is that the answer hasn’t been easy enough or popular enough to be solved (or solved properly/completely) yet, so you must put some real thought into developing a solution.
I relatively recently found an old talk on creativity by John Cleese (brilliant). One of the ideas he puts forth is that in order to be creative, one must have time set aside on a regular basis to dedicate to being creative. You have to give yourself the window of time. You can’t expect to be in meetings all day, and suddenly catch an epiphany in the break room. It just doesn’t work that way for most people.
Unfortunately, after working as a developer and security person for the last 10 years, I’ve seen very few people have any sort of dedicated time to “think”. The only common example I’ve seen are those who are going back to school after work, and therefore, have a reason outside of work to study and think hard about certain things. Apart from that, though, I’ve not seen much in the way of thinking hard thoughts. Development is bad (the exception would be design work), but security is worse. To an extent, the industry is currently so bad at security that we’re still dealing with low hanging fruit. When we don’t have to try that hard, often we won’t.
I have a theory I’ve built over time that places people in 4 rough buckets with regards to their workplace contributions and abilities. I’m specifically talking about dev/security folks, but the same is probably true elsewhere. I’ve tagged them with musical monikers for clarity (or confusion :>).
1. Tone-deaf – These are people that don’t try or are in the wrong job. It would be better both for them and you if they were not on your team (and if you didn’t have to listen to them).
2. Knows Basic Chords – These are people that can learn a task and repeat it properly. In order to move to a new task, they need to be trained on that task, but they will then perform it well. They can be solid contributors, but are not your “idea guys/gals”
3. Knows Scales – These folks can learn concepts, and apply them in various situations. They’ll often put out ideas that start with “what if we tried …?”. They have the ability to learn new things on their own and apply previous lessons learned to new situations. Folks like this often thrive in multi-disciplinary environments. They can take the abilities they have as a software security person or a plumber or a pilot and apply them to solving problems in other fields. This is the highest level most people will achieve.
4. Virtuoso – This is what a “thought leader” should mean (heavily abused term in security given those that are called that). These folks are rare … very rare. They come up with entirely new concepts. They develop ideas from scratch. In practice, and in retrospect, it’s usually a combination of a couple things that I’ve seen when working with these folks. They are a) knowledgeable about a lot of things (places to draw ideas), b) their solutions are elegantly simple (frustratingly so), and c) their solutions are further out (bigger) than everyone else’s. If you find one or more of these people in your organization, do what you can to keep them happy and learn from them.
Note 1: These buckets have nothing to do with formal education. There’s no implication that a higher level of education correlates to a higher level of capacity. However, more education might mean a broader and/or deeper set of specific skills.
Note 2: These buckets are not meant to imply that people can’t move from one bucket to another – they can and do. They often move buckets when they become more or less interested in the work they’re doing.
Note 3: There’s immense value to be found with people in each bucket – it’s just a matter of applying their capabilities properly.
In conclusion, one of the things I find myself recommending most often is “think”. Don’t just do something, think about why you are doing it and if that’s what you should be doing. This concept is universal and is not restricted to security or even technology in general. Part of thinking is being creative and doing the hard work of problem solving. There are ways to work towards bringing out your creativity and you can exercise them and get better at them. Lastly, people generally fall into a few buckets when it comes to their “thinking” tendencies at work. Recognizing these traits and using people to their strengths can help you get the most out of your people.