There are more things in information technology than were ever dreamt of in the philosophy you started your career with.
As technology has grown, so have the promises, the value, the number of actors involved, and the stakes.
In such circumstances, what chance do you stand to avert catastrophe?
That is the topic of the final act of this book, where we’ll dive into the many levels of staying in control.
Detection I should have acted on the first signals more aggressively. But let’s talk about that later in this story. Here is the story of my site being infected with malware, viewed by a professional cloud security expert. So I am going to apply all that cloud security theory to it. The hack led to business damage at the end of one of my webinars. In 2016, on a Friday, I did a webinar, at the end of which I had two links to my site as a call to action. ...
Risk is the flip side of value. For everything that is of value, there can be circumstances threatening that value. While value is realized in the past and the present, risk is what can happen with that value in the future. Risk in a digital world is not always easy to think through. While we can borrow a lot from the real world, certain important differences exist. At the core of every risk assessment there is the thing we worry about the most: the ‘asset’. In a digital world, this is often the data. Think of business-critical data, like our database of customers. Think of data that we have a compliance obligation on, such as personal data. ...
I have found that no discussion on risk is going to lead anywhere if it does not make clear who suffers from it. Make clear who has the pain. For my phone and laptop it is easy: if I lose them, I suffer. In a larger organization it is less clear. Suppose a server dies. Whose application then no longer runs? Who has to pay for a new server? This gets increasingly harder if we are talking about shared services, because the owner and the consumer are now decoupled. ...
Let’s dive a little deeper into assets. The most relevant asset in information security is data. That is what users of information care about most. In addition, we can also see the processing power that we need as an asset. Here are some examples of data assets: A customer record in a business system An MRI scan A browser cookie (on the server) A logfile entry As you can guess from these examples, many involve regulatory concerns due to the type of data that they consist of. One of the tasks of a risk analyst is to figure out what regulations apply exactly. ...
From the moment a security vulnerability is discovered, it represents a negative value to its potential victims. When it gets exploited, it can lead to loss of data or loss of integrity of the data. This in turn impacts the victim’s business processes. For example, if personal data is leaked, reputations will be damaged, financial losses and fines can be expected. Credit card abuse forms another example of loss. This “damage potential” increases as the vulnerability becomes well-known, progressing from nation state actors, to organized crime, to script kiddies, just to name one example pathway. At first, few people know about it, but gradually more people will be able to inflict damage with it. Over time, each step adds to the likelihood of that vulnerability being exploited and causing real damage. The likelihood starts at near zero, and ends at close to 100% as the vulnerability is completely public. This only stops when an investment is made to mitigate the vulnerability, for example by updating the software. And hopefully, that investment is less costly than the damage potential. ...
Where do you start your IT security journey? It is important, but it can be confusing. For many organizations, the trigger is a compliance obligation to show that confidential information remains confidential. Maybe their customers are asking for an ISO/IEC 27001 certification, demonstrating that an IT risk management system is in place. Maybe they are handling credit cards and therefore need to worry about compliance to PCI DSS. Controls The common theme in these is that they are control based. The process is that you realize compliance by implementing a set of controls, such as defining a password policy, or implementing a type of firewall. ...
For people who care about risk in IT, compliance is a mixed blessing. Compliance regulations can lead to better risk management, but sometimes it is more of a hindrance than a help. Compliance in IT generally means compliance with regulations that are set up to reduce risk, for example, across a chain of actors. A great example is the PCI/DSS regulation, which governs everybody who touches a credit card transaction. The objective of this regulation is to protect card holders and card issuers from credit card fraud. The reason why the regulation exists in the first place is because negligence at one actor can lead to damages at another actor. ...
Even in a cloud world, reducing server count is a lofty goal in itself. After all, you would be paying for all those servers anyway. Understand that sticking all your servers in a private cloud makes them more flexible, but not necessarily more efficient or cheaper. Back in 2012 I did an interview with a guy who has a full time job in keeping those server counts down. Ron Kaminski is a capacity planner at Kimberly Clark Corporation (KCC). This interview is a composite of several conversations I had with Ron at the annual Computer Measurement Group (CMG) conferences, and a number of messages Ron wrote. ...
Zero Trust Architecture is an approach to better cybersecurity. To many, it seems daunting to implement. But it does not have to be hard to start. Consider this hypothetical situation. You have an application with hundreds of thousands of sensitive records, let’s say client records. We assume that in this example it seems hard to implement MFA (Multi Factor Authentication) on it. What other controls can you implement to reduce the assumed trust? We can use the Kipling method, which is at the core of Zero Trust architectures, to engineer better controls. In short, the Kipling method is about the “who”, “what”, “when”, etcetera of allowed communication. ...
Cloud is too important to leave to technical people. Cloud distributes responsibility for IT services across an IT supply chain. This supply chain is composed of independent providers. This implies that there are these companies have technical boundaries that are matched by organizational and contractual boundaries. This is new, we did not have that before the digital revolution. Amazon calls this the shared responsibility model for cloud security. I would simplify that as: what do I do, and what do you do? For example, who is responsible for patching the Operating System in an IaaS service model? ...