For many years we’ve been hyped with the cloud generation of computing with the likes of giants such as Amazon, Microsoft, VMware and Oracle to name a few in the ring. But moving entirely to the cloud has some considerations to take into account and a Cloud Risk Assessment is to be conducted to analyse the possible risks you may be placing your data in. On the up side cloud reduces internal costs, internal resources providing companies with better efficiency and flexibility to maintain data usage loads and scalability.
Every once in a while it’s good to take stock of a situation. A projected 1.25 billion Android users for 2015 (according to Gartner) is such a situation. Either your organisation is already an Android shop or it is likely to become one in the near future. A plethora of software apps for the Android OS and a decidedly spotty security record for many Android users means that reviewing your approach to Android security could be a wise move as well.
One of the bugbears of IT network security is the denial of service (DOS) attack. Instead of (or as well as) trying to sneak past a firewall with a few innocent-looking data packets, the DOS attack tries to cripple a network or a system by swamping it out. In the case of network firewalls, the attacker will try to generate as much network traffic as possible to overload the firewall’s processing power. Attackers often multiply the sources of the network traffic for that reason, leading to distributed denial of service (DDOS) attacks. Firewalls that are submerged by traffic may become unmanageable, unless the vendor has taken suitable design precautions, which might also inspire good business continuity in general.
Middle East Respiratory Syndrome (MERS) is a new threat for humans. Also known as ‘camel flu’, it is a viral respiratory illness first identified in 2012 in Saudi Arabia, where so far it has caused over 280 deaths. Since then it has spread to other countries. As of late June 2015, South Korea was the second most affected country, with 31 fatal casualties. People infected with Middle East Respiratory Syndrome coronavirus (MERS-CoV), to give it its full name, develop fever, coughing and shortness of breath. Although the symptoms are recognisable, the transmission of the virus has yet to be properly understood.
For business executives and marketers, as well as IT departments, the following paragraphs on the secrets of cryptography hold a useful lesson. First a quick recap on what this is all about. AES stands for Advanced Encryption Standard, used to keep your data confidential. The 128 and 256 numbers refer to the size of the ‘key’ that is used to encrypt your data and then to decrypt it so that you can use it again. In an intuitive marketing sense, 256 should be significantly better or ‘stronger’ than 128. This sounds good, but is it of any practical use? Or is it simply fulfilling a psychological need rather than a technical one?
What does it take to get PC or server backups to work properly and bring computers back to operational status? Correctly stored data files are a critical component for most organisations. However, on their own they won’t let you get back to business. You’ll also need the applications that generated those data files and you’ll need the associated configuration and profile information. That includes user and account-specific information and any purpose-built software modules to link your system to others in your enterprise. The smart solution would be to back up all of this information within the same process.
Data encryption should be a good thing for security. When your data is encrypted using today’s encryption standards, other people cannot decode your files or your information. Data at rest encryption (DARE) takes care of the data sitting on hard drives, while data in motion encryption (logically DIME – you read it here first!) ensures that it remains confidential while being transmitted from one point to another. However, like the petard or bomb that blows its user up, encryption can sometimes backfire.
When it comes to singling out sectors that are in the forefront of disaster recovery, finance is often quoted as an example. With so much depending on the ability to recover systems and data rapidly after any incident, major banks were among the first to implement hot failover data centres for instance – as well as being among the only organisations that could afford them. At the other end of the scale, there are those that are particularly ill-equipped to deal with IT disasters. The education sector has been identified as one example, but another group falling short of the levels required could surprise you.
Risk management is one of those areas that are too often “somebody else’s responsibility”. Whether through lack of knowledge or indifference, it gets shunted off somewhere else and replaced with an approach of “it’ll be alright on the night”. Unfortunately, it frequently isn’t. Like business continuity or information security awareness, risk management should ideally be everybody’s business and accepted by each member of an organisation as an individual as well as a collective responsibility. Risk management on a per-project basis can help move the needle in the desired direction.
For many people, IT security is about keeping the bad guys out of the data centre by using firewalls to control external access and anti-malware programs to prevent hackers from infecting servers. That is only half the picture however. The threat that has also been growing comes from people already within the security perimeter of the data centre. They have legitimate access to servers, but are misusing that access either unintentionally or deliberately to take data out. The challenge in resolving this kind of insider threat is that it is typically not a malware attack, but a personal ‘manual’ attack.
If you’re wondering how much risk management should become part of your organisation’s rulebook, you may already be looking around to see who else is doing it. Insurers and bankers are obvious examples, because their businesses are centred on risk calculation, whether in terms of setting insurance premiums or defining credit interest rates. Many insurers are also ready to discuss risk management with potential customers in a variety of different industry sectors. These can range from agriculture and aviation to sports and transportation. However, there are other perhaps unexpected examples that show how far the concept of risk management has spread in general.
Does resilience in your enterprise spring from its senior management as a source of inspiration to all? Or is it perhaps embedded in your organisational culture, lovingly nurtured and developed over the years? Either possibility would be gratifying. However, some recent information suggests that neither is the primary source of resilience. Researchers Sarah Bond and Gillian Shapiro surveyed 835 employees from a cross-section of firms in Britain and found that 90% of those employees considered their resilience to be inherently within themselves; and only 10% thought their organisation provided them with resilience. If this is true more generally, there are some important consequences for any enterprise to consider.
Now that management science has taught us how to quantify so many other things, crisis management is a good candidate for being awarded its own scale of seriousness too. The detail you put into such a scale will depend on how much crises afflict your enterprise. If you are battling a continual stream of problems, your scale may be finer (say, 1 to 10), in order to sort out the life-and-death situations from the nuisances. Otherwise, a high-medium-low system of ranking may be sufficient, as long as there are clear definitions for crises to be categorised correctly. So, how does this work in practice?
‘Agile’ is still a buzzword. That’s quite a feat in today’s high-speed business and technological environments, where concepts date so rapidly. The original ‘Manifesto for Agile Software Development’ appeared in 2001, some 14 years ago. Since then, the word and the concept it labels have been applied to different business areas, including marketing and supply chain operations. Recently, it has also cropped up in the phrase ‘agile recovery’. But is this taking the ‘agile concept’ too far?
By conventional standards, business continuity cannot exceed one hundred percent. Business continuity of less than 100% is obviously possible, although measurements of just how much less may only be approximate. However, if everything is working properly, full business continuity has been achieved. Does it make sense to then talk about ‘fuller than full’ or a business continuity index that is more than 100%?