Fundamentals of Information Security
Getting Started with Information Security
The course is part of this learning path
This course introduces you to the fundamentals of information security. You'll learn what information security is, the difference between information security and information assurance, as well as the fundamentals of information security.
- Get a foundational understanding of information security
- Understand the difference between information security and information assurance
- Learn the fundamentals of information security
This course is intended for anyone who wants to improve their knowledge of risk management in an information security context.
We recommend taking this course as part of the IT Security Fundamentals learning path.
Hello and welcome back. We spoke about information assurance and information security and how they fit together overall. As you can see, we have the strategic planning happening over there and this is more tactical and technically focused. And the stresses with our technologies; security applications and software infrastructure, building actual infrastructure, all that type of stuff comes in to play in and around this arena. And then we have the information assurance to make sure it's all doing its job, so that we get that feedback. So, metrics become a very important thing overall.
So these are the fundamentals of information security, and as you can see, there are three of them. We have processes, technology and people. The least reliable component of the security triangle is the human factor.
Information security is a combination of those three things, as is actually taking care of security. Putting good processes in place, combining them with technology, and then making sure we've got people to take care of those actual processes and that technology.
So this kind of falls around the cyber security style area that we're actually attempting to take care of, but it spreads out into information security as well.
The things that we are using to protect information security, those same three tenants are the very things that people will attack. We can attack processes for an organization by anticipating or knowing a security process. I know how to circumvent System A, and I wonder if it works in a similar way with a different system. So I'd be looking at things such as how to circumvent the process, leave the process, start the process, how users are added to the domain, and the technical process, etc.
Technology. If we understand the technology, we can hack it! We can break it, we can get around it, and that's what we always aim to do if we are attacking a system. And then, obviously, people. There would be no point of having all these great processes and technology in place if we didn't actually have trained workers. The users are the important things in cyber security or information security. What can the company be liable for, if something were to transpire? If they have certifications, there are legal obligations to train users. Otherwise, the company begins to automatically fall short of their own certifications and not be compliant to the standards.
So, training is important. It's also important to make sure individuals can actually do the jobs you're employing them for; that's the other reason why these are important.
Let's take antiviruses and technology. What does antivirus actually do first and foremost? It tries to protect our systems from viruses that may be trying to circumvent the vulnerabilities that exist in them. Okay, in order for that to continually work, it has to be up to date. Then it has to be tested and proven to work within the organization, which essentially means testing and training are intertwined. We test the antivirus system and train it for our organization.
In order for that to work properly, we can't just update it and all the rest of that, but in order for that close-up thing to happen, we need a process. So we need a policy. We need a policy that's going to tell us how to maintain the software and how it needs updating. We need a process and a policy that's going to tell us how we actually deploy in the first place. You know when we do an individual deployment are we deploying from AD? What are we doing? How does it work? Does it get deployed with the image once we first do it? How do we update it? Everything goes into that process, and then obviously the correct maintenance as well.
That process needs to be taught to somebody. We also need a process that's going to come into play when things go wrong. How do we then use that technology to get the best abilities to help the organization? Processes have to be put in place, we have to know them, we have to understand them, but we can't just have the policy and process in place. They have to be communicated to people within the organization, otherwise they’re worthless. And they’re even more worthless if you've got the processes there and nobody understands them.
Antivirus is just one technology that we've taken as an example. It could be the technology or just the actual machines people use, and the process by which they approach emails (which may look suspicious) and then educating them as to how to actually use their systems as well as the pitfalls and dangers and the processes: how they engage themselves with the process when they see an email.
As you can see, that all comes together again. You've got the technology, you've got the process, and the rest. Then you have to calculate risk.
Okay, so here's the security policy. Security policy is important. Security policy falls on laws, regulations, requirements, organizational goals and objectives. We have to know what we have to do, what we will actually want to do and what we'd like to do - and the overall objective, which is normally to make money.
Now, some of these things we call intrinsic and extrinsic issues. So, essentially, internal issues and external issues - external being the laws, the regulations, and requirements from standards that we're held to. And then the intrinsic issues being the organizational goals and objectives. We'll put those all together, along with a bit of risk management, and then we’ll design a general organizational policy that'll cover our organization in terms of information security, and then we'll have functional implementing policies like your antivirus policy, your clear desk policy and all the rest of that sort of stuff.
And under those, you'll have standards, procedures, baselines, and guidelines. So those will come into play now, under those functional implementing policies.
So let’s say we’re gonna do a password policy. Here's our password policy and let's throw a standard in there.
In fact, this is how it works. Our policies are overarching statements about our position on something. So, our password policy might be something such as: 'everyone in the organization must have a secure password'. So let's do that. There we go: 'everyone in the organization must have a secure password'. Great, that's our policy.
Underneath that, we're going to have to make that stand up, aren't we? We can't just say it, we've got to back it up. So what do we back it up with? We back it up with some standards. For example, a password policy standard might be something like: 'add at least 8 characters, with at least one capital, one special character, no recognisable words, etc., etc.', and a change date requirement. However, you need to keep the policy usable. If you make users change a password too often they are more likely to write the password down, which is, of course, not secure.
So that's our password standard sitting under our policy. What type of procedure can we have under there? If I was going to write a procedure, let's make it simple. We've got a procedure whereby we change passwords. We build our procedure... Procedures are just instructions essentially, or sets of instructions, that get us to fulfill our standard. So we'll write into our group policy. So let's put there, 'Standard will be enforced by group policy and monitored.' So that's our procedure. This standard, then, is going to be governed by the actual technology and that will build our procedure. So every time someone writes a password or they try to go and change their password, AD will kick in, apply the standard, and the procedure of handling those passwords and people changing them. And then underneath AD, there'll be a process or procedure. We can even write the procedure if we're building our own systems or software.
Underneath, they would have a guideline and the guideline goes to the people that are actually going to change their passwords or people interacting with our systems. And our guidelines are just best practices as to how to best create passwords that fit our system.
So it would be something like: 'Go to the portal, try making a password that is something like...', 'Go to your web browser, use the Find Three Words App, reverse those words backwards. Add some random characters and try that way.' It's a "try that way", it's not prescriptive as to what you must do in order to create the password. It's a guideline to help you get to where you're supposed to be, so that you can actually adhere to the standard. So guidelines aren't mandatory procedures, but standards are.
Baselines are mandatory as well. Baselines themselves are essentially standards, if you will, that we build for particular systems, and we use those so that we actually know what's required for different environments.
Originating from a systems administration/network architecture career, a solid part of his career building networks for educational institutes. With security being a mainstay his implementation he grew a strong passion for everything cyber orientated especially social engineering. The educational experience led to him mentoring young women in IT, helping them to begin a cyber career. He is a recipient of the Cisco global cyber security scholarship. A CCNA Cyber Ops holder and elected for the CCNP Cyber Ops program.