The overall approach to developing a cybersecurity program, as with any venture should begin with pulling together a description of what is needed and why, to proceed to define how it is going to be implemented, when, and using which methods. Many components go into the development of a security program:

  • Authority: For a successful security program, there must be the right balance of responsibility and executive authorisation.
  • Framework: A security framework provides a defensible approach to developing the security program
  • Assessment: The assessment of what needs to be protected, why and how leads to a strategy got improving the overall security posture
  • Planning: Detailed planning produces priorities and timelines for security initiatives.
  • Action: The actions of the security team produce the desired results based on the plans.
  • Maintenance: The end phase of the parts of the security program that have reached maturity is to maintain them.

Figure 1-1 depicts how a complete security program implementation would look like in a midsize to the large enterprise environment. Smaller companies might simplify, streamline, or combine components depending on resource availability. These security program components, and how they fit together, are described in the following sections of this article.

Authority

A security program charter defines the purpose, scope and critical responsibilities of the security organisation and gives a formal authority for the program. Usually, the security organisation is vested with the responsibility for information protection, risk management, monitoring and response. It might also be responsible for enforcement, such as reprimanding or even terminating employees or contract workers, but more commonly that responsibility is vested in the Human Resources department. Other duties may include physical security, disaster recovery and business continuity planning, regulatory and internal compliance, and auditing. The set of responsibilities varies from company to company and should be specified in the security program charter, which should be authorised by the company’s executive staff. The ongoing strategy for providing the headcount needed to operate the security function is a resourcing plan. Insourcing, outsourcing, offshoring, consultants, service providers, and temporary workers will be leveraged to fuel the progress of security implementations, operations and ongoing improvement.

Framework

The security policy provides a framework for the security effort. The plan is set out to describe the intent of the executive management concerning what must be done to comply with the business requirements. The policy drives all aspect of technical implementations, as well as policies and procedures. Ideally, a security policy should be documented and published before any applications begin. It is essential that the security policy represents business decisions about what to do based on certain assumptions. If these assumptions are not documented, they may be unclear or conflict with other activities. Documenting these assumptions in a clear, easy to read, easy policy helps communicate expectations to everyone involved.

Standards are the appropriate place for product-specific configurations to be captured in detail. Rules are documented to provide continuity and consistency in the implementation and management of network resources. Rules change with each version of software and hardware, as features are added, and functionality changes and they are different for each manufacturer. As regulations do improve, a periodic revision to reflect changes in the software and hardware to which they apply should be carried out.

Furthermore, guidelines for the use of software, computer systems, and networks should be documented for the sake of the people who use these technologies. Guidelines are driven to some extent by the technology, with details of how to apply the tools. They should therefore also be driven by the security policy, as they describe how to comply with the security policy.

Assessment

A risk analysis should be carried to provide perspective on current risks to the organisation’s assets. This analysis is then used to prioritise work efforts and budget allocation so that the assets with greater risks can receive a more significant share of attention and resources. Risk analysis results in a well-defined set of risks that the organisation is concerned about. These risks can be mitigated, transferred, or accepted.

A gap analysis should also be performed, which compares the desired state of the security program with the actual current state and identifies the differences between the two states (desired and current state). The differences, or gaps, form a collection of objectives to be acted on over the course of a remediation efforts to improve the organisation’s security posture to bring it in line with one or more standards, requirements, or strategies.

Remediation planning takes into account the risks, gaps, and other objectives of the security program as a whole, and puts them together into a prioritised set of steps to move the security program from where it is today to where it needs to be at a future point.

Planning

In the planning stage, a roadmap should be defined, which is a set of action for how to implement the security remediation plans identified and documented during the assessment phase. It describes when, where, and what is planned. The roadmap is useful for managers who need the information to plan activities and to target specific implementation dates and the order of actions. It is also a valuable tool for implementers who will be responsible for putting everything together. The roadmap is a relatively high-level document that contains information about major activities and milestones coming up in the next defined period (often some combination of quarters, one year, three years, five years, or a “rolling” period that advances periodically).

A vital piece of the security program is the security architecture, which documents how security technologies are implemented, at a relatively high level. It is driven by the security policy and identifies what goes where. It does not include product specifications or specific configuration details, but it determines how everything fits together as a whole. For a wider audience and in particular the executive management, a useful tool for architecture documents is a block diagram – a diagram that shows the various components of security architecture at a relatively high level so the reader can see how the elements work together. A block diagram does not show individual network devices, machines, peripherals, but it does show the primary building blocks of the architecture.

Next, the project plans to detail the activities of the individual contributors to the various security implementations. A good plan should open with an analysis phase, which brings together all of the affected parties to discuss and review the requirements, scope, and policy. It is followed by a design phase, in which the architecture is developed in detail, and the implementation is tested in a lab environment. After the design has been made robust, an initial test is performed to expose bugs and problems. Then followed by the implementation phase, with the implementation broken into small collections of tasks whenever possible. Testing trails implementation, after which the design is revised to accommodate changes discovered during testing. Upon completion, the post-implementation review takes place, when the implementation team meet to discuss hits and misses of the overall project to prepare for the next phase.

Action

Next in the lifecycle of a security program development is the action phase where are formulated. Procedures describe how processes are performed by people on an ongoing basis to produce the desired outcomes of the security program in a repeatable, reliable manner.

Maintenance and support are part of maintaining the ongoing operations of the security program and its associated technologies, as part of a typical lifecycle of planning, updating, reviewing and improving.

The actions that should be taken when a security incident occurs are defined in the incident response plan. Advanced planning for what to do when security incidents occur helps shorten the response time and provides repeatable, reliable, and practical actions to limit the scope and damage of an event.

Maintenance

In a security program, policy enforcement is necessary to ensure that the intentions of management are carried out by the various people responsible for the behaviour and actions defined in the security policies. Often, this enforcement is a shared effort between security management, company management, and Human Resources.

Security awareness programs are used to educate, employees, business partners, and other stakeholders about what behaviours are expected of them, what actions they should take under various circumstances to comply with security policies, and what consequences may ensue if they don’t follow the rules. As an educational tool, an awareness program can also be an excellent resource for helping people understand why they should want to follow the rules, and how security benefits them.

The ongoing guidance for business projects, daily operations, and general walk-up questions is an integral part of a security program. After all, business situations change every day, and security should be considered in every case. It is essential that someone is available to advise the business on the best way to do things securely.

The Impossible Job of The Defender

A general truth about security, regardless of the application, is that the job of the attacker is always more straightforward than the position of the defender. The attacker needs only to find one weakness, while the defender must try to cover all possible vulnerabilities. Figure 1-1 illustrates this concept. The attacker has no rules – the attacker can follow unusual paths, abuse the trust of the system, or resort to destructive practices. The arduous task for the defender is to try to keep their assets intact, minimise damage, and keep costs down to the barest minimum. To illustrate this, I will use the analogy of a typical business, businesses who want to protect their properties must try to anticipate every attack that is likely to happen, while attackers can merely use, bend, break, or mutilate the property’s defences. Businesses have the grimmer job, trying to protect their assets against all types of evolving attacks.

security program components diagram

security program components diagram

The business as the defender has an impossible job if the goal is to have 100% protection against all inconceivable attacks. That is why the primary purpose of security cannot be to eliminate all threats. Executive management may need to be educated about this concept, because they may not realise that this is a tenet of the security profession. Every business should perform a risk assessment by choosing which threats to defend against, which to take out insurance against, and which to ignore. Mitigation is the process of defence, transference is the process of protection, and acceptance is deciding that the risk does not require any action.

 

Security Program: Strategy and Tactics

A security strategy is the definition of all the architecture and policy components that make up a complete plan for defence, detection, and deterrence. Security tactics are the day to day practices of the individuals and technologies assigned to the protection of business assets. Said in another way, strategies are usually proactive, and tactics are often reactive. Both are equally important, and a successful security program needs to be both strategic and tactical. With a well-defined strategic plan driving tactical operations, the security effort will have the best chance of success.

Strategic planning can proceed on a weekly, monthly, quarterly, and yearly basis, and should be considered an ongoing endeavour in the organisation. There is often an immediate need to protect a part of the network infrastructure, and time is not on the side of the strategic planner. In cases such as this, a tactical solution can be put in place temporarily to allow appropriate time for planning a longer-term solution.

Adequately gauging the effectiveness of a security program, separating strategy from tactics provides a way to focus on how business resources are being deployed. If your company find itself concentrate only on policy or only on tactics, it should review its priorities and consider adding additional staff to address the shortfall. As time progresses and strategic planning is employed, tactical operations should begin to require less effort, because strategy should simplify the operation and the business processes. This simplification is caused by the organisation and planning provided by the strategic initiatives, which reduce uncertainty and duplication of work by providing a proactive framework for staff to operate in. Given sufficient time for maturity, strategic planning should encompass tactics, confining them to the point where most daily tactical operations take place in a well-planned strategic context, and only unexpected fluctuations cause reactive efforts.

In an ideal situation, strategy and tactics are at equilibrium. The strategic focus paves the way for the quarter to quarter activities, and the tactical operations follow the strategy set in forth in the previous quarters. In this balanced system of planning and action, a framework has been set in advance by the strategists for the operational staff to follow, which significantly facilitates the jobs of the operational staff who must react to both expected and unplanned security situations. Instead of spending time figuring out how to respond to day-to-day situations, the operational team follows a mostly pre-planned set of responses and implementations, leaving them free to cope with unexpected security problems. In the network security context, this allows a better focus on incident response, virus control, correction of policy violations, optimisation of implementations, and the like.

Business Processes vs Technical Controls

There is no magic bullet in security. In this sense, I mean a single security device, product, or technology that provides complete protection against all threats. Some security products are marked as “security-in-a-box” solutions that provide all the security with a company needs. In reality, security threats and exposures are complex and continually evolving. Your organisation need to select security technologies by business context, so they are targeted toward specifically identified risks with clear objectives.

Note:
There is a clear distinction between processes and tools. Often, the devices only support a limited set of methods, and in these situations, the methods may have to conform to the limitations of the tools. However, the tools only automate the processes; they do not define them or make them secure in and of themselves.

Organisations that place technical controls on their network without accompanying business processes have not recognised that computers are tools for accomplishing specific objectives and that devices should be considered within a business process to be effective. For example, purchasing a database does not solve the problem of how to manage customer data. Customer data management is a business process that can be facilitated by a database solution. Likewise, buying a firewall doesn’t magically provide security for the organisation. Additionally, if technical controls get in the way of the business or slow down workflow, the organisation employees will find ways to circumvent them, rendering them ineffective or useless.

In the context of network security, business objectives, priorities, and processes determine the choice of tools, and the tools are used to facilitate the business processes. Figure 1-2 illustrates this principle. Your organisation should note that any security implementation is a snapshot that includes the current threat model, the protection requirements, the environment is protected and the state of the defensive technology at the point in time. Worthy of note is, as the technology and business environment evolves, the technical controls that are part of this snapshot will become less and less suitable.

Before selecting security products, the organisation’s business processes must is identified so that security products can be chosen that fit suitably into the business environment. The proper thought of how the security tools will be used to facilitate the business requirements improves the likelihood that the security tools will remain sufficient and adequate. The organisation’s security practitioner must attempt to understand the underlying business processes and data flows to solve the organisation’s security challenge. This requires time and effort, but it’s necessary for success. For the security solution to be successful, this requires the security practitioner to be included in the project planning process sooner than later.

business-objectives-priorities-diagram.png

The organisation should make these assumptions when developing the security program:

  • You can never be 100 per cent secure
  • You can, however, manage the risks to your assets.
  • You have many tools to choose from to manage risk. These tools used correctly can help you achieve your risk management objectives.

Conclusion

Organisations looking at developing a security program should be aware that security implementations that solve specific business problems and produce results that are consistent with clearly identified business requirements deliver tangible business benefits, by reducing costs and creating new revenue opportunities. Security both prevents unwanted charges and allows greater business flexibility. Therefore, protection creates revenue growth at the same time as controlling losses.

The organisation can think of security in the context of three Ds: defence, detection, and deterrence – each of which is equally important. Defence reduces misuse and accidents, detection provides visibility into excellent and dangerous activities, and deterrence discourages unwanted behaviour. A security program that employs all three Ds offers durable protection and therefore better business agility (see figure 1-1). Strategies are used to manage proactive security efforts, and tactics are used to lead reactive security efforts. Together, well-designed security strategy and tactics result in an effective, business-driven security program.

References

Byrnes, Christian F., and Dale Kutnick. Securing Business Information: Strategies to Protect the Enterprise and Its Network. Addison Wesley, 2002.

Gattiker, Urs E. Information Security: Strategies for Understanding and Reducing Risks. John Wiley & Sons, 2011.

Tipton, Harold F., and Micki Krause, eds. Information Security Management Handbook. Auerbach Publishing 2001.

Stackpole, Bill, and Eric Oksendahl. Security Strategy: From Requirements to Reality. Auerbach Publications, 2010.

Herman, Debra S. A Practical Guide to Security Engineering and Information Assurance. CRC Press, 2001.

Do you find this article useful? Or do you have something informative to share? Please feel free to comment below as we welcome a variety of additions for the benefits of our readers. Alternatively, if you would like to get in contact with the author to help your company in security program development, please send an email to support@dangata.com.

Posted by Dan K Jatau Sr. MSc, PhD, MBCS, MInstLM

Dan K Jatau is a Nottingham, UK-based Information security and technology infrastructure expert and researcher who likes to write about technology subjects from both a business and technical perspective. His current interests are business-driven security architectures, identity and access, the Cloud, virtualization security and all aspects of security. He currently works in security program development and architecture and develops enterprise security programs for SMEs.