The importance of training and awareness is of course fundamental to the security management program. One of its main objectives is to identify needs and information gaps, identify audiences and topics that need to be covered. The primary goal is to address knowledge gaps, performance gaps, procedural gaps, and ensure that knowledge and the captured lessons learned have been actualized and passed on to the population that needs it the most. It must address the behavior of people through repeated training and retraining.

Now the focus should be on areas such as password selection, appropriate computer use and computer hygiene, email safety, safely browsing the web, and social engineering. Now as part of this program, employees should be taught how to recognize and escalate events, looking for signs and symptoms, and communicating that upwards to ensure that either the incident currently under investigation by them is then examined further, dissected, and the lessons learned from it spread throughout the organization.

We will always have to pay special attention to duties requiring unlimited data access, such as transferring data between systems, performance tuning, scheduling various kinds of batch jobs, programmers changing application code, and any other highly privileged tasks. Having awareness training should begin when the employee starts. And then it should periodically be reoccurring to ensure that any new developments, any new releases, any new legalities, all of those events are communicated in a timely and appropriate manner.

Programs ideally should incorporate quizzes to ensure that we're measuring the retention on the part of the employees. These kinds of programs should include reminders. These can take the form of posters, newsletters, popups on screens, lunch and learn types of seminars, and so on. Then there should be regularly scheduled refreshers as part of the routine training and retraining for our employees.

We always have to consider the following. Who is our audience? And what is the message that we are using to target to them? And how will we present them? What do we expect in the way of an intended result? What is the modality that we will use to communicate this? And where does this fall in the organizational structure? And how will this interact with the culture? Some of the effective mechanisms for raising awareness will be computer-based training, email reminders.

Obviously written security policies and procedures will be part of this. Having non-disclosure agreements and discussing the content of them and the effects of failing to uphold them. Newsletters, web pages, and videos. Visible enforcement of policies. And other methods to ensure that the employees are kept current, know that they're being measured, knowing that they are being empowered to act in a compliant way. And that, as always, there's a consequence for failure to do.

One of the areas that needs to be explored first would be the general rules of use, meaning acceptable use and unacceptable use. Creating a user-friendly summary of expectations is oftentimes quite helpful. It tells them what they should do and what they should not do, and equips them with the knowledge to make an informed choice.

With all policies, they have to be provided to the employees, because without doing so, we're unable to hold them accountable, nor should we expect appropriate behavior. Policies should always include various kinds of standards. In this case, access control, the classification scheme for information, marking and handling of documents, reporting requirements, disclosure constraints on any form of protected information, and a general email and internet usage policy.

Part of every training program should be an employee's code of ethics. Now ethics training is oftentimes reserved for employees who perform sensitive activities, but in fact should be extended to all employees. This program, when implemented, will include monitoring users, maybe penetration testing, access to personal data, or other sorts of activities to explore who's doing what with what kind of information.

Security personnel themselves should be trained in ethics and abide by an ethics code. And they need to be aware of potential conflicts of interest, as well as reporting them. Now the code of ethics should be adopted and signed by all employees to ensure that a; they're aware, and b; they operate by it.

For all of these things, there will be documentation required. The documented examples that we have very much as standards will be policies, procedures, and guidelines. Technical diagrams, training and awareness documentation, risk analysis, security systems designs, incident tracking reports and processes, and operational procedures. And in many of these cases, they will be audit artifacts as well. And so they must be preserved. And if a regulation applies, retained for a period of time.

In every case, there should be an owner assigned to each document or each document type. Documents should have enablers who can address life cycle steps for these documents. Anything that is persistent or open-ended should have version control process to make sure that everybody works with the same version.

Changes should always go through a formal change process to ensure an appropriate, controlled update. And changes to policies or standards should trigger procedure updates as well, and then recirculation and retraining of same. Now program development and project management should of course follow a standard methodology.

Just like every other type of project or program that exists within the enterprise, security should follow the same rules and the same modality. This puts it more in line with the way that the business manages itself and its affairs. It also works through a mature process to avoid causing weaknesses in other areas, more important in security than almost any other area of the enterprise.

Each project, like all projects, will need a time, a budget, and measurable risks and factors to gauge the progress and the success of it. They have to be prioritized like all, have a flow, have a task list, and be measured so that we can avoid any sort of delays.

Along with standard project management processes, we will also need to do program budgeting. This of course will depend to a large degree on resource availability, which may involve a bit of a selling process to convince senior management to approve the budget that we need for our security program. We have to be sure we're following all sound business logic, meaning that we have to lay out our strategy and a well thought out, well thought through roadmap that is put together in such a way that senior management can easily grasp what we're planning to do and what will be the proof of its accomplishment.

Now budgetary expenses typically are easy to understand. But we need to be prepared as with any business case composition. Sometimes these can be difficult to grasp for someone who is not familiar with security and the way that it's measured. Working with the program management office and subject matter experts to accurately estimate the costs associated with this, as well as working out proper, clear explanations for what is to be done and what the results will be is mandatory.

As with all projects, we have to worry about properly quantifying employee time, any fees for contractors or consultants, hardware and software costs if those are applicable, space requirements if applicable, testing resources, training costs, any travel, on down the list, just like any project would normally have.

Now in managing information security problems, we need to establish the same kind of management processes and metrics as any other similar type of function would have within the enterprise. The problem management focuses on finding root cause for any emerging or existing issues. We should identify these problems with controls and assign them priorities. Not all things are equal. So we should, of course, use something approaching the scientific method.

A logical sequence where we begin by understanding the issue, defining our problem, designing an action plan that corresponds to the issue and the problem, assigning responsibility and accountability, and as close as possible, assigning dates or timeframes for resolution. Now as with all things, plan A and a plan B might be advisable, which means we might need to implement a secondary control if primary fails. This could result in a business disruption. And so the security manager needs to take authority to implement this kind of an action.

Supply chain management never ceases to increase in importance. Looking at our vendors, we need to go through and vet them properly before we bring them on board, because vendors and especially in the security area, provide services and products that do critical functions that can be found to either protect or expose the enterprise. Some examples include assessment and auditing, systems engineering, operational support, architecture and design, advisory services, or forensic support.

Now specific to security that need monitoring, this would include financial viability, quality of service, adequate staffing, adherence to security policies, and the right to audit, all of which should be included in any services contract we execute with a vendor.

In our program management evaluation processes, as with any management process, we're going to need to periodically review how effective we are, whether we're meeting deadlines and any other metrics that we have.

Critical areas would include program objectives and how they're being accomplished, when they're being accomplished, and how close to the planned schedule that is, any compliance requirements and any problems meeting them that may arise, which should be escalated as quickly as they're known.

Program management issues, security operations management, tactical security management, and the management and allocation of resources and their levels. No project should ever begin without the program objectives being established, and the metrics for how they will be measured. This means that we have an implementation of our roadmap at a more practical level. We have to have ways of monitoring and measuring them to know that the goals are being accomplished. But we must begin by ensuring that they are realistic and sound. These need to align very closely with the roadmap and where there's deviation with explanation. 

The well-defined criteria for them have to spell out not only what we are going to accomplish, but also what the criteria will be for acceptable risk in each case. Goals have to be defined, and they have to be defined collaboratively with the stakeholders to make sure, as we always say, that everybody is on the same page.

There will be of course the need to create policies, standards, procedures, et cetera, as may be needed for the accomplishment of this program and any project or sub-project within it. And as always, we must define metrics to ensure that we can measure the success or failure of any step that we take. 

very project may have the impact of compliance requirements as defined by some regulatory source. Without question, this must be considered in the formation of any program or project. Typically it involves some regulatory standard because many projects can be performed without a concern for this. But we must know before we begin. In such cases, we need to first determine what the level of compliance is needed, what the type of compliance is needed.

A way to learn about that is to examine results from recent audits or any compliance reviews that precede the initiation of our program. We have to be sure that the compliance requirements are well understood, are very clear, and that they get integrated effectively into the program objectives. And we have to be sure that the compliance management processes and technologies are in fact working properly, and note any deficiencies and get coverage for them.

Program management is of course overarching to see to it that the program and the projects that are within it are performed properly. We have to be sure that they are well supported, and that if they are not, that that becomes revealed very quickly. The technical programs might need to be light on management, but they need to be managed nonetheless with rigor and metrics.

Now the compliance programs themselves might be heavier on management than simple tactical programs might be. But in either case, everyone must understand their roles and responsibilities, so that what is expected and what is accomplished can be aligned. These of course should be ideally reflected in performance ratings, and accountability should be well-established even before the program is undertaken. This may require documentation to be prepared or to be acquired and updated.

There will undoubtedly be policies and standards that have to be part of this, and they must be reviewed and approved by management before they're instituted. And the metrics, as always, have to be defined and clear. Once we ensure that program management is taking place properly and covering all the right elements, we have to move on to security operations management.

Security operations management is more of the practical nature of this program and where, so to speak, the rubber meets the road. Here we look at how well the program implements all of the operational activities that have been defined in the program charter and the activities accomplished by the program management.

It focuses on standard operating procedures. Looking at them, they're making sure that all of the security requirements and processes previously defined and included in them are in fact being met. It controls configuration or access management, systems maintenance, event analysis, and incident response.

As implemented, they ensure segregation and separation of duties to prevent too much authority in too few hands, and too many conflicts of interest. It validates the schedule for all regularly performed activities, and ensures that they're performed on those schedules. It operationally evaluates metrics for meaningful results and actionable intelligence. And very importantly, it ensures a pathway for escalating any issues that can't be handled at the rank and file level.