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.
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. Detection 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. ...
Trust is an essential element in any collaboration. We want to trust things, people, and organizations to do the right thing, to keep their promises. Without trust, we will not be able to have confidence in the contribution of others, and that is a risk. Anything we don’t trust is a risk. Anytime we assume trust that is not warranted is also a risk. That is one of the core concepts of Zero Trust Security Architecture. ...
Once we have assets and risks identified, we think of ways to minimize the risks that we can’t avoid or accept. Those ways are called controls or measures. A control is a promise that is made enforceable. You can budget it, delegate it, and audit it. Once you call it a promise, it becomes clear that somebody needs to make the promise, and somebody needs to acquit the promise. Presumably, somebody also has to promise to pay for it. ...
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. ...
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. ...
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. ...