Category Archives: Uncategorized

Architecture – A Definition by Andrew Townley

Leave a reply

Listen up architecture fans! I came across a great definition of architecture from Andrew Townley. I received this definition via email. I subscribe to receive emails from him. Enjoy!

The truth – and the problem – actually lies in the power of the thing the word “architecture” itself represents. The simplest version of the definition that is always guaranteed to be true is this one:

“The structure of something.”

Many definitions – including mine – add the words “complex” or “carefully designed” to that definition, but they’re not necessary.

Because everything has an architecture.

Everything.

The question is the degree to which it

  1. exhibits complexity, and
  2. has been designed—carefully or otherwise.

Organizations have an architecture, but it isn’t the wires, cables and computers inside it. It’s the collection of governance structures that defines what it is and which work together to deliver the value it creates for its customers. Once you understand this critical point, getting what you want becomes a whole lot easier—

Including security, compliance and true governance.

Krebs on Ransomware – Test Your Backups

Leave a reply

Like most people in the cybersecurity field, I follow Brian Krebs’ work. Brian posted an article on ransomware on July 19, 2021. Below are the excerpts that I found most interesting. As you reflect on your backup, recovery and testing plans for your personal information (or for your parents, 2nd cousin twice removed or kids) or the critical information for your business or employer, are you making an action plan to revise anything based on these insights (side note: make sure you backup and test the recovery of this new action plan!)?

  1. “the biggest reason ransomware targets and/or their insurance providers still pay when they already have reliable backups is that nobody at the victim organization bothered to test in advance how long this data restoration process might take“
  2. “…victims that have off-site, encrypted backups of their data but discover that the digital key needed to decrypt their backups was stored on the same local file-sharing network that got encrypted by the ransomware.
  3. “…third most-common impediment to victim organizations being able to rely on their backups is that the ransomware purveyors manage to corrupt the backups as well.”

Side note – Check out this “old” ransomware “scenario” from Cisco Talos group. This sounds like a good script to base a purple pen test on.

Krebs, quoting Fabian Wosar from Emsisoft, writes that all “organizations need to both test their backups and develop a plan for prioritizing the restoration of critical systems needed to rebuild their network.” Of course, this is basic blocking and tackling. Some people may consider this blocking and tackling boring when compared to the pen testing of let’s say a Tesla, or the forensic analysis of a Drone. Let’s be honest (with some sarcasm, but not too much) that backup and recovery isn’t as glamorous or exciting when compared to security architecture. Let’s give a shout out to business requirements gathering, threat modelling, security design assessments, or architecture design documentation. Oh yeah!

But let’s be clear: no team every wins or makes it to the Super Bowl or the “neighborhood “championship” unless they get the basic blocking and tackling techniques down! And you can’t get basic the blocking and tackling down unless you make it a priority and practice it. Let’s repeat:

Prioritize it. Practice it.

Prioritize it. Practice it.

And as the saying goes, practice makes perfect (or at almost perfect since after all backups, recovery and test plans are still run by humans at least until Skynet comes online).

Security Architecture and Reference Architectures – Key Attributes

Leave a reply

I recently wrote about a definition and the key attributes of reference architectures. Interestingly, I read an email on July 6, 2021 by Andrew Townley (go to https://archistry.com to subscribe and receive daily updates) on the same topic. Below is an excerpt from the email. It lists other key attributes of a security architecture / reference architecture…enjoy and use it.

In short, a security architecture should not be a “documentation showpiece” like a Ferrari, but a workhorse like a Ford F150…The security architecture (and reference architectures in general)…

…gets dirty.
And…most importantly…
It gets used.
It doesn’t sit on some shelf, forgotten and covered in dust.
It doesn’t sit behind glass, on display for all to see how much work was done to create it.
It’s dog-eared, scribbled over and pasted to the walls above everyone’s desk.
Because that’s where they need it.
And they need it because it helps them make the decisions they need to make to do their job every day of keeping the organization safe and serving its customers.

Zero Trust and Reference Architecture – A definition and attributes

Leave a reply

So, I have been doing more in-depth reading on Zero Trust Architecture (ZTA).

Side note – I will share my reading list in a future post.

As I read the Department of Defense’s Zero Trust Reference Architecture, Version 1.0 (February 2021) document, I came across a solid definition of reference architecture:

Reference Architecture is an authoritative source of information
about a specific subject area that guides and constrains the instantiations of multiple
architectures and solutions.

This may see simple, but I bet there is a joke that starts with: two architects walk into a bar to define “reference architecture” and….well, you get the idea.

Below is an excerpt from the scope section of the same document referenced above. I highlighted some key words that can be used to extrapolate other important attributes of a reference architecture.

The content was built to align with the DOD Information Enterprise Architecture (IEA) for consistent mapping of terminology and ease of use as an implementation reference. The scope of the DOD Zero Trust Architecture (ZTA) effort is specifically to determine capabilities and integrations that can be used to successfully advance the Department of Defense Information Network (DODIN) into an interoperable Zero Trust end state. The architecture focused on data-centric design, while maintaining loose coupling across services to maximize interoperability. Other initiatives (e.g. ICAM, Public Key Infrastructure (PKI), etc.) to protect the DODIN are not the subject of this reference architecture but may be shown in some cases to provide additional context for ZTA alignment with DOD IEAs. This Reference Architecture describes Enterprise standards and capabilities. Single products/suites can be adopted to address multiple capabilities. Integrated vendor suites of products rather than individual best of breed components will assist in reducing cost and risk to the government. This document will evolve as requirements, technology, and best practices evolve and mature. Zero Trust promotes individual journey to a collaborative goal of continuous Zero Trust enhancements, while also incorporating best practices, tools, and methodologies of industry.

So, other important attributes of a reference architecture include:

  1. Aligns with a larger and single Enterprise Architecture
  2. Uses consistent language and layout for ease of use and orientation by customers
  3. Defined scope
  4. Outlines what is not in scope
  5. Describes standards and capabilities
  6. Evolves and is updated as requirements, technology and best practices changes, mature or evolve

What is your process to monitor emerging technology?

Leave a reply

I will write a post soon on a process to monitor emerging technology.  The key benefit of proactively monitoring emerging technology is to uncover unknown business problems and associated technical solution and to go faster to market with technology.  It also provides architects greater time to design and prepare for potentially disruptive technology.

The best known and potentially disruptive emerging technology is “block chain” (especially bitcoin).  This topic deserves several discussion by itself.  Please see a good summary of blockchain at ZDnet.com.  For example, I found this description of blockchain and bitcoin useful: think of blockchain as the ‘operating system’ upon which different ‘applications’ (such as Bitcoin) can run.

The Takeaways

  1. Develop a service/product that delivers recommendations on either ignoring, monitoring, testing or adopting emerging technology
  2. Continue to monitor and develop use cases for blockchain.

 

What is the “Second Economy?”

Leave a reply

Chris Young at his keynote at Focus 2016 reflected on some trends over the last year. One of his observations, which is also expanded on in Mcafee’s book “The Second Economy,” is that threat actors or “black hats” use time against defenders (see below for excerpt from book).



Three years ago, the trend and focus was about threat actors prolonging the attacks. That is, it is about being persistent in the environment as long and stealthy as possible to harm the victim. It is about extending the length of the attack(s). The persistence can be by the original threat actor or a new threat actor that has purchased access from the former. Of course, these persistent  threats are still occurring.

However,in 2016, with the increase in ransomware attacks, threats actors are now using time to pressure victims to avoid long term harm (i.e., a hospital cannot treat patients in their ER department because their computer systems are unaccessible). It is about shortening the length of time of the attack as much as possible.

The Takeways

  1. Read “Second Economy”
  2. Communicate to your stake holders about ransomware and how time is being used against you