From these activities, we're going to create a Baseline. And the baseline serves as an initial set of observations used for later comparison. It's establishing the baseline which are the things that we want included and the things that we don't want excluded. But identify so that we'll know the difference.

From this, we seek to maintain the baseline through the security controls and other activities that we'll perform to continuously manage our risk. Consequently, we must set a minimum security requirement that must be achieved to show that we are established and achieving it through our actions, and that our actions are effective. It must remain consistent with acceptable risk levels. Acceptable risk being a standard that management has set based on their criteria.

The baseline must of course include compliant achievement as a vital ingredient. From this baseline, once established, we should be able to routinely and on hopes easily measure changes from the baseline through any change that occurs in our operations. It also allows us to set different baselines for different classification levels assuming that we have them.

Low classification data may require less stringent requirements than high classification data. Each organization's baseline will typically be unique to that business, or to the particular division of its business, or the particular system. Because this is not a one-size-fits-all sort of standard.

One question that always needs to be asked, whatever decision we make, whatever choices and risk mitigation we make. We always have to ask ourselves, is it in fact secure? Good security review processes take that question and employ it. They seek an objective. In other words, what you hope to get out of a review? What you should find? A scope, it tells you that what the assets are within that. And their fair game for the evaluation.

We will have within our security question, a list of constraints. Which may mean boundaries that will restrict what the reviewer can do within it. It has to describe an approach. Which is the way in which we will carry out our specific objectives. And it will tell us what the result should be. That way we know whether or not we've actually achieved our goals and what success looks like.

An equally important question is concerning how much security is enough? So we asked the question just how secure is it? One of the ways that we verify this is through audits. And the audits have the same five components in the process but are expressed in levels of effectiveness. We're trying to make sure that we accurately and appropriately measure in context, how well a control that we have in place meets the stated objectives.

The audits result in work papers that map out how controls are compared and applied to various objectives, and how they meet them. What the team did to test the controls. A vital step with vital intelligence value from it. And we will link the test results to the final assessment showing how effective or ineffective they may be.

In the case of mature programs. Audits indicate if policies and procedures have been fully implemented and are being fully and appropriately followed. Conversely, immature programs, the audits will measure compliance against external standards, such as COBIT, the ISO 27000 series, or others.

Now auditors are in fact, a great ally. They're a member of the team that helps the organization achieve its security objectives by identifying areas where we may be weak so that the security staff can address them appropriately.

Now, the results can emphasize much needed actions to senior management. And the consequences of failing to address them, justify taking those actions. Now looking at technology. We have to look at it from the standpoint of it needs special kinds of treatment. The age of a system may not prompt us to avoid implementing security. We have to look at the changes that our program will require and keep change to a minimum that is appropriate to the context.

An example of this may be that we may not apply tactical access controls to an old system, but we may choose as an alternative in this case a compensating control, to apply physical access instead. As a more cost-effective solution to achieve the same end. Tactical security comprises the majority of our security work, but not the only approach that can be taken.

Frequently the security manager is considered to be the resident expert. However, opinions vary. And in fact, it is a team approach led by the security manager. This is often based on how the organization itself views the security program and the manager's role. In such a role, we need to understand architecture, our implementation principles, our quality measurement, and the processes that accomplish them. We need to be able to accomplish these things from the standpoint of addressing these areas.

Looking at the perimeter, which is our furthest extended point where we make contact with the rest of the world, through our networks and systems. We have our applications and this involves what sort of coding practices do we have, and what sort of exposures we have through it.

We have the database. One might say the vault where all of the data of high value exists and then examine how it integrates with all of the applications that seek to use and manipulate that data. And we mustn't forget to involve the physical aspects as well, for both operational and environmental security augmentation along with the technology.

Now, our enterprise resource planning process can add certain elements. One of the things that it adds is how much downtime will hurt. When downtime occurs, the systems are unavailable. Working without these systems to support our efforts can make things much more complex even to the point of becoming impossible. And if our enterprise resource planning system goes down it could impact the entire supply chain.

Now, throughout all of this we have two processes that are shot through the entire thing. The first one is Due Care, which is recognizing that we need to examine these areas for security, risks, threats, vulnerabilities, in order to help us decide proper mitigation treatment.

Along with that, the turning over every rock and examining every weakness in every situation, is Due Diligence. Where we leave no question unanswered. And what due diligence looks like. Usually involves the following steps. We have full senior management support, and in fact they are who we are reporting the results of our due diligence investigations too. It involves a comprehensive review of the policies, standards, procedures, baselines, and guidelines. In the environments context. 

It includes an examination of what security education, if any, is present. It looks at periodic risk assessments, assuming that they're performed and what the results and subsequent actions are going to be part and parcel of that will be our backup and restore processes.

Implementation of security controls and how well they're monitored and manipulated to improve their performance. Monitoring and using measurement metrics to see how we actually measure up as a quantitative indicator. We have to look at compliance and what standards apply and how good of a job we do with that.

We will of course have to examine our business recovery processes and our disaster recovery processes. As we look at the asset being protected by all these things, the data and the information that the aggregation of data produces. We have to be sure that it is in fact protected that the measures that are used are appropriate and effective.

We also have to look at our complete supply chain, looking at outsourced contracts to make sure that they have the appropriate security language. And then taking the next step to ensure that the vendor to the given contract is in fact meeting the standard stated. And then as always, we have to do a periodic review of all of these areas and have the infrastructure of the external parties.

Now looking at industry standards. What we have here is we have a listing of the most common of these. Now virtually every company in every industrial section has a various forms of regulatory and even business best practices that they have to adhere to. Amongst these will be controls that control access to information to only authorized parties.

Now, standards exist from non-industry specific organizations. And these reflect best practices. And these typically are what are applied first, because there's no legal consequence, but in fact these are good standards that can make up application of legal requirements easier.

Following this will be the application of regulatory standards on top of those, trying to ensure that there's no overlap or confusion or conflict between them. For example, we may apply an ISO standard first, and then make changes for compliance with HIPAA if we happen to be in the healthcare market.

On the right hand side of this slide, we have a listing of sources of these standards. And as you can see they're at the top, we have the AICPA and it's Canadian counterpart the CICA. We have COSO and the rest of the standards that typically applied to industrial sectors, or ones that applied generally across many of them, such as those that come from ISACA, ISC squared, the IT Governance Institute, the National Fire Prevention Agency. And so on.

One very crucial element of this risk management program, will be the staying on top of vulnerabilities. Vulnerabilities are characterized as a flaw or a weakness in a system or a control structure that leave us as the name indicates, vulnerable, to an adverse impact from a threat or a failure. Now we find in software that vulnerabilities are rampant.

The rush to get a product out, whether it's hardware or software, frequently means short cuts in the manufacturing and production processes. Therefore, we may take it as given. That vulnerabilities exist in anything that we're likely to buy and implement. Knowing this, we should react as rapidly as we can, once we have acquired and have control over the product or the hardware.

There are organizations that are dedicated to finding and reporting these vulnerabilities. And here we've list five. US Computer Emergency Readiness Team, or CERT. MITRE's Common Vulnerabilities and Exposures Database, or the CVE. Security Focus's Bugtraq mailing list. The SANS Institute. And OEMS, the Original Equipment Manufacturers themselves in the notices that are required from them, when vulnerabilities or flaws are discovered. Resulting in product recalls.