Conclusion: The success of a security professional is not measured by whether their recommendations are adopted, but whether the technical risks faced by the organisation have been identified and communicated in terms of business impact to decision makers. This enables the business to make informed decisions. Consequently, security professionals must make it their highest priority to be in communication with the business, because one of the most impactful technical risks is a communications gap between the security team and the business. IT security professionals must take on learning the language of their business, because it isn’t the business’s responsibility to learn to speak IT security.
Conclusion: Cloud services are not similar to a highly virtualised internal environment. Nor are they similar to the tightly controlled experience of time-sharing on a mainframe back in the 1970s. The supposed elasticity of the cloud has become a point of vulnerability because the elasticity is only partial, and only at certain points. The outcome is a service which is believed to be highly resilient, but which can actually prove to be surprisingly brittle.
Conclusion: Early adopters of cloud services often swept aside security and risk concerns, as these adopters were more interested in the end – a better IT service – rather than the means. But now organisations with mature risk and governance processes are looking at cloud services and risks are being identified and assessed for their potential impact. Cloud services can dramatically improve the IT service experience of an organisation, but organisations must be completely clear on what services they are, and are not getting as part of the engagement. As with all commercial engagements, the devil is in the detail.
Conclusion: Every technology trend in the financial services sector (principally BYOD, changes in cybercrime, cloud, and DLP) has an aspect of identity and access management. IBRS research on the identity management market in Australia has found that there is a very small resource pool of sufficiently skilled practitioners. This means that the financial services organisations in Australia face a significant challenge in the coming years, primarily from a lack of good security people to architect, execute, support and monitor technical controls.
Conclusion: Identity management projects do not have a good reputation for successful delivery. Too often, the final implementation fails to live up to promises. Identity management projects can deliver genuine value to a business, including: compliance with regulation, improving customer satisfaction, or reducing risk. But if the business is not driving the project, then the project is probably off the rails and heading for failure. In this situation, CIOs must seriously consider terminating the project because a project not driven by the business is one being imposed on it – it is the tail wagging the dog.
Conclusion: IT security strategies are an invaluable resource as a means of coordinating security efforts and in improving funding approval for security projects – because they can be shown to be following a coherent consistent strategy. The process to create them is an overlooked source of value for the information that it uncovers. An IT security strategy must be closely aligned with what the business believes its security and risk priorities to be. The process of uncovering business impact against various systems is likely to bring up unexpected gaps in knowledge for both IT and the business, and it is here you will find additional gold.
Conclusion: Patching is now considered a standard part of IT operations. Vendors release patches either to mitigate against new risks, or to introduce new functionality. However, the application of a patch can not only result in the intended outcome (risk mitigation or expanded functionality), it can also have unintended consequences.
Organisations looking at creating a patching strategy should ensure that the business stakeholders are clear on the potential impact of both patching, and non-patching. Either choice carries risk. What will make the difference for organisations are security professionals who can crisply articulate the balance of these technical risks as they pertain to the business requirements of the organisation.
Up to this point I’ve been a supporter of data breach notification. Coming at the issue as an industry analyst, I think that transparent information on the local experience of data breaches (such as what information is targeted by attackers, how much it costs a company to deal with a breach, the frequency of breaches, the avenues of attack, and so on) would be extremely valuable to the industry as a whole. This is the luxurious, wide-angle, perspective which is expected of an industry analyst.
Then a story such as the hacking of Verisign comes along. In October 2011, Verisign disclosed in a quarterly report to the SEC that: “The occurrences of the attacks were not sufficiently reported to the Company’s management at the time they occurred for the purpose of assessing any disclosure requirements.”
Conclusion: As cloud services - typically Software as a Service - become increasingly accepted, the IT industry is gaining valuable experience in the actual risks of putting data in the cloud. Most of these risks centre around data confidentiality. Knowing the actual risks, rather than the fear, uncertainty and doubt that vendors and security consultants can throw at the cloud, enables CIOs to make informed choices and recommendations to the business on cloud usage.
Conclusion: Most vendors emphasise their strengths and obfuscate to hide their weaknesses when responding to an RFT (Request for Tender) for IT products and services. Detecting their weaknesses by unravelling their obfuscation is often a major task for the evaluation team or panel. Failure to detect weaknesses could lead to the wrong vendor (tenderer) being selected and reflect poorly on the team.