O ambiente ideal da segurança de informação é diferente dependendo de com quem se fala, assegura Simon Burson, consultor de segurança informática. (artigo em inglês)
Your typical security engineer may say it must have firewalls, intrusion detection or any number of security focused technologies. Meanwhile a security tester may suggest that it is conducting penetration testing to provide assurances that security widgets are working well.
This article attempts to provide a usable checklist to ensure the foundation is in place for an organisation to be as secure as it can reasonably be, given that it is operating in its own unique enviroment.
Information security can not be prescribed in a single checklist that suits all organisations. Information security is about adopting the right measures and controls for a given entity at a given point in time. Threats change and vulnerabilities are introduced or removed, demanding that security evolves simply to keep pace.
Checklist Item 1: Appointing a security officer
Every organisation should assign a security officer even if the role is given to an individual who wears multiple hats. Larger organisations may establish a dedicated position – the chief security officer who presides over a team of specialists addressing the different areas of information security.
The security officer is the central point for managing proactive and reactive information security tasks. The day to day activities for the individual resources that work in the domain will depend on the size and focus of an organisation but ultimately the security officer role should be accountable for the following:
• Strategy — identifying the security posture an organisation wishes to maintain and how this will be achieved.
• Operations — monitoring of security alerts and management of security assets, for example intrusion detection, jump hosts, firewalls and scanning tools.
• Architecture — ensuring security is designed into the businesses technology and processes.
• Consultation — providing consultation to projects or business units by way of requirements, reviews, recommendations and risk assessment.
• Analysis — researching products or specific technical issues to assist in provisioning of technology or remediation of vulnerabilities.
• Testing — providing security testing such as penetration testing for projects and rolling assurance exercises.
• Emergency Response — responding to emergency security incidents such as the compromise of information assets or the loss of service through a denial of service attack.
• Programme manager — acting as the business sponsor for a rolling security programme of work.
Checklist Item 2: Security reporting
Reporting provides a “heartbeat” for information security across an organisation. It ensures the right people remain up to date on the latest incidents, threats and initiatives that will influence the security posture. Regular reporting ensures those that are accountable for securing information assets are aware of the risks they may have inherited and the rigour in the controls that protect them.
Security reports must be written for their audience and this is an area where security professionals often fall down. The content must be accurate but presented at a level that can be consumed by the target audience. Reports destined for technologists with an appreciation of the hands on should be literal and explain any vulnerabilities and controls in technical terms. Those intended for managers with a technical background should be explained conceptually and include references to technical detail that supports any conclusions. Lastly those intended for parties outside the technology group such as the CEO or chief risk officer should wholly focus on the business impact where the conclusions are justified by a well-designed and established process rather than a series of technical whitepapers.
Checklist Item 3: Develop governance
For an organisation to maintain a consistent security posture people within that organisation must have clear instructions that tells them how to behave. Governance ensures that people are aware how they should conduct themselves and if well constructed encourages them to behave in a way that maintains or may even improve security. There are useful standards such as those produced by International Standards Organisation, National Institute for Standards and Technology and the Government Communications Security Bureau that can be used as a suggestion of best practice or simply as inspiration.
Checklist Item 4: Develop a security incident management plan
Every organisation will experience a security incident. The impact of that incident and the likelihood of it repeating is directly impacted by how an organisation manages it.
Was the incident clearly identified, validated and contained? Was the vulnerability that led to it identified and is there a plan to remediate or apply additional countermeasures? Was the incident reported to an appropriate authority inside the organisation and do any external parties need to be notified? These are but a few questions that are answered through a well formed security incident management plan.
The plan should identify a front door for people reporting potential incidents. From there it should define an auditable process that validates the incident and initiates a response team well placed to deal with it. The owner of the plan is the security officer who remains a central part of the response team. The plan will dictate how the incidents progress is recorded and what if any information is disclosed to a wider audience. Typically it will empower the response team to operate outside governance, bypassing change control and other processes that are designed for business as usual rather than an unforeseen emergency.
Checklist Item 5: Initiate a security programme of work
Security initiatives require a vehicle to carry them through design, build and implementation. Grouping them all in a single program of work allows for budgets to be managed more easily and ensures the investment in information security is transparent. Upgrades of security devices such as firewalls and antivirus may be included in the programme, as well as any capital investment in information security, such as an identity and access management system.
The security programme should be primarily focussed on enhancing information security and be funded at a level that an organisation considers appropriate. The security officer should have a list of initiatives in order of priority and the allocated budget should fund those at the top of the list.
Checklist Item 6: Assess the security of all initiatives
An unfortunately common observation is that organisations invest heavily in security controls in one area but due to budgetary constraints ignore others. For example the website may have extensive technical controls and receive frequent security testing while the “trusted” third party connections are left unchecked. Often this is due to incorrect assumptions being made by the business on what the security implications of an action are.
A security assessment should be focused on empowering the business to decide whether an initiative should progress, change direction, be reviewed at a more detailed level or in the most severe cases be halted.
Checklist Item 7: Complete period-based assurance tasks
While assessing the security of all initiatives is a proactive way of ensuring security is built in, it is also important to be reactive. With the best intent and design, it is possible for vulnerabilities to be introduced into a technical environment through human error or as the result of an aggregation of technical anomalies. Completing periodic assurance tasks is intended to identify and manage vulnerabilities that may not have been foreseen.
One of the most commonly practiced assurance measures is penetration testing. It provides a high level of assurance that the tested technology would be resistant to a targeted attack by an skilled attacker. It is however relatively expensive and often tightly scoped. Given the specialised nature of security testing it could be worth considering using a third party security practitioner. A practitioner can ensure that the scope is appropriate and that the tester is reputable.
Checklist Item 8: Provide security training
Security training is a widely recognised requirement for a mature organisation; but all too often the bare minimum is provided, such as an induction session which ensures everyone knows they shouldn’t write their password down.
Induction training is a great idea but beyond making people aware of the security policy, it should be different for different roles. Members of the executive face different threats and employ different countermeasures to those holding a position on the help-desk. The former will likely require a one on one sessions while the later may be inducted as part of a group.
While security training may seem expensive, it is probably one of the best returns on investment for an organisation. Guarding against one phishing attempt may be the difference between winning the next big contract or recovering from an embarrassing information leak.
Checklist Item 9: Develop a whistleblower process
Securing an organisation is not limited to the practices of security specialists. It includes everyone from those cleaning the office (often with unparalleled access) to those on the board. It includes partner organisations and their staff and their partners and so the list goes on. Along with supporting (or opposing) security controls, staff and third party affiliates are a useful source of information about security events. They may observe vulnerabilities or even be aware of vulnerabilities being exploited. This information is extremely valuable and should be captured and processed to aid in improving ones security posture.
Reporting of shortcomings is not always something that a hierarchy does particularly well. There is little incentive for a middle manager to report a shortcoming in an area he/she is responsible for. It may lead to embarrassment or additional work and for these reasons potential risks can be swept under the rug. A solution is to develop a whistleblower process which allows anyone to report a perceived security issue to an information security authority in confidence; without fear of repercussions.
Checklist Item 10: Consider security functionally
A challenge that faces many organisations is the apparent power that security practitioners require to do their job. They often have super user rights on a system to provide oversight or control access and they often report to senior management even though they aren’t necessarily executive level managers themselves. Security is a functional requirement rather than a hierarchical one.
In designing security roles and responsibilities the function of that role must be considered as a focus on hierarchy will weaken an organisation’s ability manage information security well. It can mean the removal of critical information flows as security reports are summarised into something more general. It can risk unnecessary spending on security products to imply progress in the absence of consultation to the right level.
This top ten isn’t a silver bullet. In order for each of these items to be effective they must involve an experienced security practitioner and such people aren’t that easy to find. Engineers can build the firewalls and testers can break them but in the first instance someone is required who can decide whether the firewall is required or not.