In my previous article on Zero Trust for Applications, I concluded with how we need to focus on ZT approach for code compile/build and for application execution. Next, let’s take a look at the workloads/devices on which these applications run. The movie quote from this article is taken in reference to HAL 9000 , an AI that goes rogue in “2001: A Space Odyssey”. Rogues AIs are an interesting question, but the implication from the movie remains the same for a rogues device on the corporate network.

This will be Part 3 of my series of articles on Zero Trust. Applications perhaps receive the least amount of attention when it comes to implementing Zero Trust. The level of trust given to applications is often surprising considering the rate at which vulnerabilities are being discovered (yes, title quote is from The Matrix). The tendency is to protect the device, network and the data and assume applications will automatically be protected within this sandwich of security.

This will be Part 2 of my series of articles on Zero Trust. And let’s start with data, the “chewy core” of the traditional M&M Information Security model. In the traditional cybersecurity model, data is protected via encryption and access control, and an entity (user or device) gains the “trust” to the decrypted data by fulfilling some authentication and authorization requirements. However, there is no real-time check on whether the basis for that trust has changed.

Zero Trust is a term attributed to Stephen Marsh and mentioned in his ’94 doctoral thesis “Formalising Trust as a Computational Concept” (link to original thesis ). The more than 200 page thesis delves into aspects of defining Trust and it’s relationship to Time, Memory, Optimism vs. Pessimism, Pragmatism vs. Realism and other variables and attempts to arrive at a mathematical definition of Trust. Fortunately for us Cybersecurity practitioners, Zero Trust has since been studied, developed and evolved into a much simpler concept and security architecture.

After some discussions with peers from other organizations, I was surprised by the lack of automation and end-to-end process for managing phishing incidents. So, without much preamble, let’s jump in to what an IR playbook would look like that relies heavily on automation. Scenario: Acme runs their email on the cloud (eg: O365) and already has an anti-phishing filter service deployed that effectively blocks most phishing as well as spam emails.