Know the Risk: Digital Transformation's Impact on Your Business-Critical Applications REGISTER >
But how do we ''older'' Information Assurance experts help bring in and train people to understand it?
A very good friend of mine recently decided to change career fields -- moving from being a computer programmer to information assurance. It was interesting to hear how she went about getting ready for such a move, where she did research and some of the obstacles she faced. As an Information Assurance professional, I thought I would share some of the highlights in the hopes that we can use them when training our junior folks.
First there are the acronyms.
As my friend put it, we talk in ''IA speak''.
So, the first thing we should do with our new employees is introduce them to the acronyms and language of Information Assurance. A good place to start is the acronym or glossary appendix from one of your agencies' System Security Plan or System Security Authorization Agreement (SSAA). These should contain those acronyms used both in the Information Assurance world, as well as those specific to your security environment.
There also are national-level documents that provide information assurance words, acronyms and definitions. I would recommend using the National Information Assurance Glossary, dated May 3 (NIST Inst. 4009), from the Committee on National Security Systems (CNSS). It's a good starting point.
There also are many websites that serve as good references for new (and old) Information Assurance professionals. One of my personal favorites is the Information Assurance Security Environment (IASE) that is maintained by the Defense Information Systems Agency (DISA). This website provides a great overview of the IA disciplines, as well as additional links to documentation. However, if you are not on a .mil address, you may not be able to get to all the information.
Another website for IA policies and processes is the Defense Security Service (DSS) IA site. Familiarity with the buzz words of this business will allow new employees to follow conversations, begin to recognize terminology and have the pieces start to fall into place.
The next thing my friend did to prepare for her career change was to conduct research on the various Information Assurance disciplines and the activities associated with each discipline. For example, what does ''risk assessment'' really mean, what activities does the process require and what are the outputs used for.
Many of the IA processes, on paper, are straight-forward and easily accomplished. Additionally, there are a multitude of automated tools to assist. Unless the philosophy of why a certain activity needs to be accomplished is understood, the output is useless. We all know that ''garbage in means garbage out''. The same is applicable to IA processes.
For example, let's say a vulnerability scan is run against an agency's systems. The output of the scan always identifies vulnerabilities. If the people executing the vulnerability scan do not understand why they are running the tool, then they would not know that the output needs to be carefully reviewed to identify what are false-positives and what are real vulnerabilities.
Taking it one step further, if there is no threat to match the identified vulnerability, then there is no risk, as risk equals threat times vulnerability.
So, how do we teach this?
The first step should be reading the directives and guidelines on the Information Assurance processes.
The government has provided numerous guidelines. The National Institute of Standards and Technology (NIST) has done a great job in writing guidelines for IA areas. There is an online library which contains all the guidance they have developed. Another good source is the Information Assurance Security Environment (IASE). New employees should become familiar with the various Information Assurance processes prior to executing the process. By doing this, the individual can apply the theory to actual practice, and often this is what clicks for them.
Last but not least, is on-the-job training.
Being mentored by a senior IA professional is invaluable. Since much of the IA field is subjective, we need to pass on our experience and knowledge to those below us. Using the above example, by sitting with the junior individual and reviewing the scan output, the IA expert would be able to fully explain the false-positives, and test procedures to implement before installing the patch/fix, etc.
More and more individuals, like my friend, will be entering our career field. Let's make sure we assist them in becoming IA professionals who go beyond being paper pushers and really come to understand our field.