Let’s face it, in the CyberSecurity profession, we like to learn things the hard way. When the term computer security first came about, it was in reaction to events occurring and not necessarily by design. Someone broke into a network/computer system and the boss pointed a finger at the first person outside his/her door and said go fix it, make it stop. With that, the first computer security pro was born; born out of necessity.
There weren’t any checklists or guides back then; it was on the job learning. If you were smart, you’d repeat the good processes again and again. If you were really smart, you’d show others how you did it, and why you did it that way.
That is how I got into the game.
Fortunately for me, I had some of the masters as my teachers and mentors, those who wrote the book, so to speak. The key word here is 'mentors.'
Fast forward to today.
We now have certifications which demonstrate that you know a minimum baseline of knowledge in a certain topic area. We also have degree programs that offer a more robust approach to information security. There are more specialty areas that I ever thought possible.
However, I have recently come to realize that there are more and more security professionals that are so focused in their specialty area, that many are challenged in connecting the dots as to how it relates to other areas of information security. For example, what the security process flow might be from policy through to implementation.
No matter what your “focus area” is—whether it is an infrastructure security specialist or an application security specialist—you should understand the basics of why you are doing what you are doing and what the interdependencies are. You should be able to see the WHOLE picture and understand why it is the way it is.
Let me see if I can explain.
I was working with an IT support group recently that needed to define, implement, and audit their logging policy and procedures. This is something that most IT people just “do” without really thinking about it—they just do it. However, this IT group pushed back and wanted to understand what exactly needs to be logged. This made me realize—although many go through the motions, they don’t necessarily understand the reasoning behind “why” they do what they do.
In this case, I walked the team through the very basic exercise of understanding the criticality of the applications and data sensitivity to then apply the CIA (Confidentiality, Integrity and Availability) model—this made so much sense to them. Asking that they look at each server, enabling event logs for each based on the CIA model gave meaning and purpose; such as if a server was business critical to the organization, but didn’t necessarily have any sensitive data on it. For example, for their email server – they’d probably want to log/alert on availability. If it was a server that contained sensitive data, they would want to ensure the confidentiality and integrity by logging who was accessing it (confidentiality), and what actions were taken (integrity). The task of logging no longer became a “I have to do this because the security team told me to” type of activity.
I have had a couple of other experiences lately that made me come to the same conclusion. Cybersecurity has become so driven by standards and checklists, that the reasoning behind the actions are lost. It is up to those of us in cybersecurity that understand the reasoning to begin mentoring those who will be filling our shoes. We all know the dangers of applying security safeguards based on checklists versus risk. We need to teach the whole picture; the interdependences; the understanding of risks. If we don’t, they lose... and we lose.
About Candy Alexander
Candy has nearly 30 years experience in the security industry working for companies such as Digital Equipment, Compaq Computer Corporation, and Symantec. She has held several positions as CISO (Chief Information Security Officer) for which she developed and managed Corporate Security Programs.