51. Third-Party Service Providers
We also want to consider thirdparty service providers. I mean, we realize there are going to be times when your organization must outsource. So there are some things we should consider for using third parties. And those are things like does the third party have appropriate controls in place? Is there an appropriate risk management clause in the agreement? Does the third party perform their own risk assessments? What is the proper level of due diligence that I require from that third party? And what is the complexity of the management that can be incurred by using a third party? So when you think about these things as a whole, we really realize that we’re under a contract with them, but we don’t manage that organization, not unless they allow us in there. And so we have to look to see if they are using the same diligence that we do for determining their risks, doing their own risk assessments, having their own security strategy, and hoping that it’s still in alignment with our business objectives.
That’s something else we have to make sure is that the use of the third party is helping support the business. So a lot of times there may be very complex contracts to get these agreements. And I have seen times when, as I mentioned before, when companies want to do credit card processing, that if they want to directly interface with the bank for credit card processing, the bank literally may send an assessment team. Out there to do their own risk assessment of that corporation, to determine whether or not they meet that same level of basic safety and security, that they want to be able to interact with them. In other words, by bringing a third party into the bank, you’re you are incurring a new potential of risk.
52. Working with Lifecycle Processes
So here are some considerations you should look at when you’re outsourcing. Number one, there is an increase in your information risk. Other people are working with your information and they very well could lose that information outside of your control. I realize that sometimes when a company like Microsoft that is guarding the secrets of their source code and some of it has been released to offer and it is found that it was released because they were working with a third party to develop, maybe an application or to tweak a service working with Windows, with Microsoft, and they have control of that source code. And if they aren’t as secure, then losing that information is just as bad as if Microsoft lost it themselves. So there is that increase in that information risk.
We have to realize there is a separation of responsibilities, meaning that it’s harder for us to manage. There’s also a separation of control responsibilities. If your control is your policies and procedures, that’s not necessarily their policies and procedures. If the control is something more targeted, like a firewall protecting traffic into your company, that’s not the same firewall used to protect the traffic going into that third party’s organization. So we have that separation. We also have to look to see does that third party fall into the same regulatory enforcements that we might be under? And if not, do we need to make sure that they are adhering to those because they are a contractor with our organization.
So again, it’s adding complexity, making it more complex to assess the actual business function, more complex to do the assessment of the outsourcing provider itself. And of course the fact that there is a new assessment you have to do from outsourcing. So now it almost sounds like I said the same thing twice, but I just want to clarify it. One is we’re assessing the provider of the outsource and the fact that we’re using outsourcing adds in that extra bit of assessment that we have to look at. So a little separation there as far as what I’m trying to convey when we say there’s some added complexity.
53. IT System Development
Now in the software development lifecycle. As we talk about SDLC, we can see an example of the lifecycle process. You know, we have the original initiation of this project itself, phase one. And throughout that process, as a part of phase one, we should be thinking about the underlying risks that we should be understanding, the type of data that we’re going to be storing or the information we’re going to be working with, what’s the user interface looks like, who should have access to it. All of these are a part of the initiation as well, of course, as developing the underlying structure for what it is you’re going to develop. And then, of course, phase two is the development or the acquisition.
Now, during the development process, again, we may have milestones that we reach that we can still run assessments to see where we are, to see what has come about as far as the development process for the changing of risks or the reassessment of risks. At some point when it’s done with the development process, we move into the implementation. Through the implementation, again, we have to worry about the deployment, right? As far as how we actually get this asset out into the wild, if you would like to say it that way and that’s of an issue, right? We have to worry about the implementation, about people trying to circumvent security, understanding the secure communications process.We might need to be able to push the information out once it’s implemented.
We have the regular operation and the maintenance of this asset of whatever it is, again that we’re using. And that again means that it could be the change. Where we talked about change management, we want to check the validity of the information going in, the validity of information going out, that might be a part of the overall assessment, again, just throwing out examples of what we have to look at. And of course, at some point, when we go to the end of life and we go to the disposal of that asset, if we were to talk about hard drives as an example, we need to make sure we have an appropriate set of steps or procedures in place to do that correctly so that we aren’t inadvertently giving away information, causing our own loss of information, by the way, in which we dispose of the assets when we’re finished with them.
54. Project Management Part1
When we take a look at project management, we look and see that risk management is a part of the overall project management. Maybe not in the same systematic manner, but it is a part of the project. The lifecycle approach should be considered for use in project management to help better support risk assessment. Because again, as you look at that project from that entire life cycle, we ought to be looking at risk assessment all the way along that life cycle span. Now, if you have periodic reporting of the project, that kind of helps reflect the idea of the concept of what’s called the Earned Value Management or EVM. So it is actually maybe a benefit to say that we want to be able to provide risk assessment work with risk management throughout the life cycle of a project to get a better earned value of management.
55. Project Management Part2
Part of your project management might be to define baselines. Now, a baseline technically is just a line that serves as a basis or foundation for a known measure or position. That’s as about as vague as we can get on the baseline. Now to the evolving nature of It hardware and software. You should have a regular evaluation of what your baseline is. Now, if you’re thinking about that, as far as as hardware, you may have ideas of what the minimum requirements are for a server’s hardware, how many processes It has, how much memory it has, storage capability that you never want to go below that baseline. For software solutions, you may have the same thing.
When we’re talking about security, we have what we might call the minimum basis of security. We call that our baseline. Again, it’s a position or a point or a measure of where we want to be. At worst case scenario, that’s at least how I look at the baseline. It’s my starting point. That means that over time, as we do increase hardware, as we do increase software, as we introduce new assets and potentially new sets of risks, that means that there should be an ongoing assessment of the risk and the evaluation of that so that we know our baseline, if it’s still good, where it is, or if it needs to be changed. It’s common to rate a security baseline as the minimum amount of security that you need to have, as I’ve said before, and maybe even a minimum amount of security as employed throughout an organization.
Another example of a baseline might be where we have a password policy that says you need to have at least eight characters in length of a password. It must be complex and must be changed every 30 days. Over time, you might realize that new techniques of attacks might make it very easy to crack an eight character password. And so now you have to change the baseline appropriately as your new minimums and say, now your passwords have to be ten characters long. That doesn’t prohibit a user from making a 20 or 30 character password. But we are providing again, that what I call that minimum, a baseline of what we need to have for that particular security issue.
56. Lesson 8: Risk Monitoring and Communication
Now, we’ll talk about risk monitoring and communication. And we know that we need to have an ongoing set of monitoring of the controls in order for us to manage risk. I mean, without an ongoing set of monitoring and metrics that we can be able to look at and control, how do you know that we’re in compliance or that we’ve even met that baseline that you have? The results of these evaluations should also be communicated, which means is that there must be some appropriate communication channels set up and established so that we can have that ongoing set of communications to let you know that, yes, we’re in compliance or maybe there’s a problem that we need to address.
Now, even though your senior management will likely have very little interest in all of the details, it is at least important that they get an overview of the current status. They need to make sure that they’re doing their job to know that, hey, you ultimately are responsible. And from all the reports we’re telling you, things are looking good. Or there’s an issue with a certain control that we need to address. Now, some of this might be indicated just through reports that you might color code them as red, amber or green reports kind of having a threat level assessment of the reports. Green’s letting them know everything’s going well. Red is telling them they better pay attention because we have some sort of issue we have to address.
57. Risk Monitoring and Communication
One of the increasingly popular types of reports for monitoring risks is use of what we call the key risk indicators of the Kri. Now, these reports can provide early warnings of possible issues or areas that pose particular risks. The Kris are specific to each part of the enterprise and will vary depending on the number of parameters as well as the environment that you’re working in. Some of the things we look at when we’re doing the selection for an effective Kri might be to look at the areas of things like impact or the effort it would take to implement or measure or report, to talk about reliability and of course, of sensitivity.
58. Other Communications
Some of the other communications. Usually, sometimes the greatest risk in the organization is the people. And so we need to communicate with them. Now, we have to realize that people can cause damage, whether it’s by accident, by mistake, by lack of knowledge or maybe even malicious intent. But through the use of training and awareness techniques, a part of communications, a lot of the threats can be reduced. Our goal is to help people understand how a procedure works so they don’t make mistakes when working with some of the assets to make sure they understand why we have certain procedures or standards in place and letting them know of the importance and the relevance to the security, giving them the knowledge of what’s happening.
And with knowledge they can become more aware of what they’re doing. Hopefully, with communications and training we reduce the number of accidents. Now, we should also have the appropriate documentation existing regarding things like risk management policies and standards because we need that documentation to be able to effectively manage risk. Now, the objectives and the audience, the information, the resources, the assumptions, those are things that would compose this type of documentation that we use.
And I think that the documentation should be there after any risk assessment is done through the use of risk management, so that we have those foundations and we have knowledge that we can share and make sure that everybody who needs to know this information can be fully aware of where we stand when it comes to risk management.
59. Domain 02 Review
Well in this domain. Our goal is to talk about risk management, of course, and we talked about a lot of the areas as far as establishing a process for information asset classification and ownership. Talking about implementing a systematic and structured information risk assessment process to ensure that your business impact assessments are done periodically and the reasons why they’re important for us and how they work in the overall risk management process. We talked about ensuring that your threats and vulnerability evaluations have been performed.
We talked about ways to identify and periodically evaluate your information security controls and your countermeasures that we use to help mitigate our risks down to an acceptable level. We also looked at ways of integrating risk, threat and vulnerability identification and management into a life cycle process and being able to report about significant changes or just reporting in general to have that open line of communications with regards to your information risk and but also making sure we are reporting to the appropriate levels of management.
