markasimos - Network

Hey all, this video covers several important topics: 1️⃣ How to ensure security notifications are set up right to ensure get the right...

Hey all, this video covers several important topics:

1️⃣ How to ensure security notifications are set up right to ensure get the right people working on it right away.
2️⃣ How different SecOps/SOC roles work when they get a notification from an external party like Microsoft (including some commentary on outsourced SecOps/SOC providers)

In particular, the discussion that Michael Howard started on communicating what happened is critically important to avoid future similar incidents (and getting stuck in a 'groundhog day' loop)

Making sure another incident doesn't happen again requires doing a root cause analysis and working with engineering and operations folks in the IT/technology teams.

I know these relationships can sometimes be strained, but buying everyone a pizza and beverages to sit down and talk about the incident and what can be done (short and long term) to avoid future repetitions can go a long way to avoiding future pain. Attackers _WILL_ try the same thing again and blocking IP addresses is about as effective as trying to stop a rainstorm with a water glass.

If you assume breach in a Zero Trust approach, each failure becomes an opportunity to learn and get stronger rather than an opportunity to assign blame.

https://www.youtube.com/watch?v=ieLqmkPJ8Gk

Are you focusing on the important parts of cybersecurity first? It's critical to ruthlessly prioritize in cybersecurity because there is...

Are you focusing on the important parts of cybersecurity first?

It's critical to ruthlessly prioritize in cybersecurity because there is an infinite number of ways that attackers could possibly attack your systems.

What you need to spend time thinking about is what is easiest and most effective for the adversaries, not what is possible.

You can use the 3 P's to remember what to focus on first:

1. Prevalent

2. Proven

3. Possible

Never go to the next stage until you are done with the first stage.

If you are tempted to research that cool new technique you just heard 'nation state X' did against a high profile target but you haven't effectively mitigated password spray or pass the hash, STOP!! 🛑⛔🚫🛑🛑!!!

…go back and take care of those basics before wasting your precious time and effort on something that is likely not to affect you.

The attacks you will see most are the ones that will get the job done easiest and most reliably for attackers:

1. Attackers will prefer prevalent well-known methods with a successful track record

2. They will fall back on other proven methods that are also likely to work

3. …and most will explore other potential options if needed (and if they have the skills/resources/funding/etc. to develop those into usable attack methods).

This slide visual is from the upcoming Security Matrix standard from The Open Group that captures this implication.

For a copy of this slide, see the downloadable MCRA deck - https://aka.ms/MCRA

For a webinar discussing the security matrix and other current and upcoming standards from The Open Group, see https://aka.ms/TOG-standards

April 2025 version of MCRA is out!This release of the Microsoft Cybersecurity Reference Architectures (MCRA) focuses heavily on updates...

April 2025 version of MCRA is out!

This release of the Microsoft Cybersecurity Reference Architectures (MCRA) focuses heavily on updates related to standards and mappings, products and technology changes, and more.

Key changes since the previous December 2023 release:

◾ Updated main capabilities diagram to add Microsoft Security Exposure Management, Windows LAPS, passkeys, and Microsoft Entra Verified ID as well as to show Microsoft Security Copilot as a broad capability.
◾ Replaced several references of Secure Score with Exposure Management
◾ Clarified representations of Microsoft Security Copilot to show broader capabilities beyond Security Operations
◾ Added Microsoft Entra ID Governance to Adaptive Access diagram
◾ Updated several slides in introduction sequence and added new “Security must be integrated everywhere” slide.
◾ Updated slides in Artificial Intelligence (AI) section
◾ Added ‘Standards Mapping’ section and included proposed drafts of Zero Trust Reference Model standard from The Open Group (and Microsoft product mapping to them)
◾ Added roles list from The Open Group to people section
◾ Added Prioritization slide to the Threats section from upcoming draft Security Matrix standard from The Open Group
◾ Updated threat intelligence daily signals to 78+ Trillion and updated links/resources on various slides.
◾ Updated closing slides to show the full security modernization journey and associated Microsoft Unified engagements

Download the PowerPoint file (including slide notes) from the usual site - https://aka.ms/MCRA

Does your organization formalize security experts as a powerless scapegoat? If your security team is blamed for decisions they don't...

Does your organization formalize security experts as a powerless scapegoat?

If your security team is blamed for decisions they don't make, then your accountability structure is broken. Cybersecurity people are subject matter experts like lawyers, finance professionals, HR professionals, physical safety experts, etc. whose job is to give sound advice to decision makers that have to reconcile all sorts of risks and opportunities.

Unfortunately, many people often incorrectly believe that "cybersecurity is the security team's job" and blame the security experts, which is wrong. It's not acceptable to blame lawyers when managers choose to do something illegal (unless the lawyers gave bad advice) but this is somehow ok in security.

Most incidents are the result of actions by...
◾ External attackers (and sometimes insiders)
Who exploit weaknesses in the organization's systems resulting from decisions by...
◾ Business/technical team members (not on the security team)

The business and technical team member decisions were often inadvertent (nobody decided 'we are going to make it easy for attackers to take down our business operations'), but the end result is the same. The risk impacting decisions results from hundreds of variations like clicking the link on a phishing email or setting budget / productivity targets so tightly that its not possible to apply security patches and configurations to systems.

Organizations absolutely need to hold security team members responsible for providing sound advice that is tailored to the business situation and to competently perform their specialized roles to respond to incidents, etc. But this cannot be a substitute for everyone recognizing they have an impact on security and performing their own security due diligence.

Organizations need to adopt a normal/rational accountability model where security subject matter experts are held accountable for _sound advice_ and decision makers are held accountable for _all outcomes of their decisions_.

We are focusing on laying out how to do this in an upcoming standard from The Open Group. I discuss this more in this article - https://www.linkedin.com/pulse/security-roles-responsibilities-mark-simos-09fbe

I just wrote a line that encapsulates so much of the core problem most security teams face. --Delegating the security outcomes of business...

I just wrote a line that encapsulates so much of the core problem most security teams face.

--

Delegating the security outcomes of business decisions to a security team (without the power to change the original decision) formalizes security as a powerless ‘scapegoat’ where their only real job is to accept blame when those decisions end badly.

I just posted an article with proposed draft standards text for Security Operations (SecOps/SOC) roles and responsibilities. This is for the...

I just posted an article with proposed draft standards text for Security Operations (SecOps/SOC) roles and responsibilities. This is for the upcoming security roles and glossary standard from The Open Group.

Feedback is welcome!

https://www.linkedin.com/pulse/people-matter-security-operations-roles-mark-simos-ayz5c

Recording and slides are now posted here - https://publications.opengroup.org/d333Share and enjoy!

Recording and slides are now posted here - https://publications.opengroup.org/d333

Share and enjoy!

Cybersecurity maturity is stuck in the proverbial basement. It would be hard to claim that the cybersecurity industry is 'defined'...

Cybersecurity maturity is stuck in the proverbial basement.

It would be hard to claim that the cybersecurity industry is 'defined' on any maturity model given that we haven’t even agreed basics like roles and job descriptions, basic terminology/definitions, effective controls, etc.).

Its not particularly surprising given how new the industry is (a few decades old compared to architecture and building materials that have been around for at least 25-35 centuries).

It's also extremely hard to defend against well-funded, creative, and intelligent attackers while managing intense pressure to not fail from regulators, business leaders, governments, the public, and ourselves. Adding to the challenge is that many people (including those in leadership positions) think security is a problem to be solved and that security teams have 'failed' if there is a breach (when security is actually an ongoing risk to manage and most of the decisions that lead to breaches have often been made outside of security teams).

Join this webinar to learn how The Open Group is helping by defining standards and guidance to address critical hidden gaps that link together other guidance (NIST, MITRE, etc.). These show how to build effective security risk management collaboratively across security, technology, and business teams without the blame, technology myopia, or ivory tower thinking.

This is the first webinar of a series that will help you plan, prioritize, and execute effective security. We will take you through the currently published standards as well as in development standards and guidance in the Security and Zero Trust Body of Knowledge that will give you actionable guidance and best practices whether you work in security, IT, or a business role.

Sign up here!

https://www.opengroup.org/events

I will be presenting one of my favorite new slides/graphics on a webinar on 27 March.Attackers have different motivations and use a lot of...

I will be presenting one of my favorite new slides/graphics on a webinar on 27 March.

Attackers have different motivations and use a lot of different techniques, but the models/methods that attackers operate in generally fall into these six categories:
◾ Steal Money
◾ Extortion/Ransomware
◾ Outsourced provider
◾ Espionage / Data Theft
◾ Prepare for future attacks
◾ Destruction/Disruption/Defamation

The first 3 are primarily used by criminals and the second 3 primarily are used by governments (though there are plenty of exceptions, crossovers, and hybrids in this complex space).

This graphic is from proposed material for the upcoming Security Matrix standard from The Open Group

Feedback is welcome as always!

Sign up for the webinar here - https://www.opengroup.org/events

Attackers love getting privileged accounts like IT admins because they know it gets them instant access to all the goodies. They also know...

Attackers love getting privileged accounts like IT admins because they know it gets them instant access to all the goodies. They also know that they can easily steal credentials by compromising the device (workstation/laptop/etc.) that the admins log onto.

If that device isn't secured well, then the chances of a very very bad no good day increase dramatically.

One of the best things you can do to reduce risk of a major breach is to increase the security of the devices used by admins. We documented a progressive set of controls to increase device security (while minimizing impact to usability) starting from everyday enterprise devices (we don't endorse BYOD for admins) to specialized devices (more locked down) to full privileged access workstation (PAW) configurations at https://aka.ms/PAW

Looking for clarity from the typical confusion of cybersecurity?Join Hasan Yasar and I for a session to learn about our bold vision (and...

Looking for clarity from the typical confusion of cybersecurity?

Join Hasan Yasar and I for a session to learn about our bold vision (and progress on) open standards for Security and Zero Trust to connect and organize security.

This session (hosted by The Open Group) will give you an insider’s view of upcoming standards including the Security Roles and Glossary, Zero Trust Implementation Guide, and the Security Matrix. Learn how modern risk management standards are redefining connections to Open FAIR risk quantification guidance.

These provide practical security for a complex changing world and address critical industry gaps – including the challenges posed by AI – while bridging the divide between fragmented security practices and standards.

This integrated Security and Zero Trust Body of Knowledge builds on released standards like the Zero Trust Commandments, Zero Trust Reference Model, and Security Principles for Architecture as well as the de-perimeterisation heritage of the original Jericho Forum®.

This is the first of a series and will give you actionable guidance and best practices whether you’re a software or security architect, IT operations leader, or business professional focused on security.

Sign up here!

https://www.opengroup.org/events

While poor technical tooling is only one source of SecOps burnout (see graphic), it is an important one. It is extremely frustrating for...

While poor technical tooling is only one source of SecOps burnout (see graphic), it is an important one.

It is extremely frustrating for triage (Tier 1) and investigation (Tier 2) analysts to have to keep investigating the same 'groundhog day' incident over and over again. This is even more frustrating if that detection is a false positive and if the work to investigate and document it are manual and repetitive (making it more likely you make a mistake, which adds further frustration).

The wheel of pain in the graphic shows this can turn into a (downward) cycle. If it gets bad enough, some people fully burn out on the job and quit (often in the false hope that it will be better different organization). This adds more work to the overburdened analysts that are left behind, adding further exhaustion and frustration.

While hiring new people to replace them sounds like a quick fix (and does help in the long term), it also adds additional burden on the people there to take time off of working the queue to spend time training and supporting those new folks until they get up to speed.

Its critical for SecOps leaders and practitioners to recognize this cycle (and other sources of burnout like lack of recognition, doing other peoples jobs, etc.) and help break it.

People do their best work when they aren't frustrated, burned out, and exhausted.
◾ Make sure you are hiring enough people
◾ Make sure you are sharing incident summaries with the IT folks so they know why and how to block attacks
◾ Make sure you are looking at automation and tools that reduce false positives
◾ Make sure you have processes to remove noisy alert sources with low true positive rates
◾ Make sure to thank people for their hard work and buy them some pizza or beer sometimes to show your appreciation

What are you doing to reduce burnout?

[Graphic is from SecOps/SOC module of the Security Adoption Framework (SAF) that shows how to build a modern capability using Microsoft technology - https://aka.ms/SAF ]

I just posted an article with proposed updates for the next draft of the Identity and Adaptive Access Management (IAAM) capabilities and...

I just posted an article with proposed updates for the next draft of the Identity and Adaptive Access Management (IAAM) capabilities and their supporting Architecture Building Blocks (ABBs).

This covers the advent of adaptive access, digital identities (from external organizations), the need to apply identities to everything (including obligatory meme :), and other changes like integrating key and certificate management.

Feedback is welcome!

https://www.linkedin.com/pulse/clarity-matters-identity-access-capabilities-mark-simos-xmkde/

The recording for this webinar is now posted - ...

The recording for this webinar is now posted - https://www.invokellc.com/events/revolutionizing-network-access-from-antipatterns-to-zero-trust-with-microsoft-entra

Share and enjoy!

Was it really a “Breach“? Really? Cybersecurity is full of terminology misuse and misconceptions, especially around Breach, Incident,...

Was it really a “Breach“? Really?

Cybersecurity is full of terminology misuse and misconceptions, especially around Breach, Incident, and Compromise.

The Open Group is working to clear this up with updated definitions for these terms in an upcoming roles and glossary standard.

These terms and definitions were drawn from the real world experience of the Microsoft Detection and Response (DART) team that helps customer investigate major incidents and sees this confusion (and its negative consequences) all the time.

What do you think? Does this match your expectation and experience for these terms? Is the wording clear?

Trying to figure out how to modernize 'scan and shame' vulnerability management into a true posture management program?The Posture...

Trying to figure out how to modernize 'scan and shame' vulnerability management into a true posture management program?

The Posture Management rapid modernization plan (RaMP) lays out the steps to get you quick wins and incremental progress on that journey. See graphic from PDF on https://aka.ms/CISOWorkshop

Deciding to adopt a Zero Trust strategy is just the tip of the iceberg.While Zero Trust is simple in concept (remove false assumption that...

Deciding to adopt a Zero Trust strategy is just the tip of the iceberg.

While Zero Trust is simple in concept (remove false assumption that network perimeter can keep business assets safe), security itself is highly complex.

This makes transforming security complex because it causes you to look at everything you do and know about security with fresh eyes to see if it relied on that false assumption (it's inside the firewall so it's fine) and figure out:
◾What needs to be changed
◾How to change it (and how much)
◾What to do first, next, and later

This is why we are working on extensive standards at The Open Group and why Nikhil and I are authoring the Zero Trust Playbook series. https://www.amazon.com/dp/1800568665

I just published an article describing all the roles with security responsibilities and/or accountabilities across business, technology,...

I just published an article describing all the roles with security responsibilities and/or accountabilities across business, technology, &security teams.

Also discusses how important it is to start accountability correctly at the top of the organization.
https://www.linkedin.com/pulse/security-roles-responsibilities-mark-simos-09fbe

We kept working on the proposed updates to the Asset Centric SecOps capability and ABBsRecent changes include: ◾ Expanded "ACSO-1.1.1...

We kept working on the proposed updates to the Asset Centric SecOps capability and ABBs

Recent changes include:
◾ Expanded "ACSO-1.1.1 to Incident Investigation, Containment, and Remediation" (from Incident Investigation)
◾ Expanded "ACSO 1.1.2 to Incident Impact and Root Cause Analysis" (From Incident Impact Analysis)
◾ Clarified 1.3.2 to be "_Custom_ Detection Engineering"
◾ Added "ACSOP-1.1.1.1 - User Interaction Process" (L4)
◾ Added "ACSOP-1.1.1.2 - Technology Team Interaction Process" (L4)
◾ Added "ACSOP-1.1.2 - Incident Containment and Asset Recovery Process" (L3)
◾ Renamed "Operational Analysis and Optimization Process" to "Operational Excellence Process"
◾ Renamed "SecOps Learnings integration Process" to "SecOps Change Management Process"
◾ Added "ACSOP-1.1.6.3 - Detection Source Management" (L4)
◾ Added "ACSOP-1.1.6.4 - User Reporting Process" (L4)
◾ Added "ACSOP-1.2.5 - SecOps Automation Management Process" and moved "ACSOP-1.2.5.1 - SecOps Custom Development Process" to L4 to reflect that automation needs to be managed and doesn't always require full custom development.
◾ Renamed ACSOP-1.3.7 & ACSOP 1.3.8 to reflect that they are both focused on different types of anomalies (technical vs. behavior)

Thank you for all of the feedback and let me know if you have any more comments/questions/etc.

Hey IT Admins, do you want YOUR account name in the security breach report? Are you the type of IT Admin that seeks more administrative...

Hey IT Admins, do you want YOUR account name in the security breach report?

Are you the type of IT Admin that seeks more administrative privileges and permissions? Does it seem like that will make your job easier? That you will have a more important job/role in the organization.

Those may be true, but don't forget that "with great power comes great responsibility” also applies to administrative privileges.

Having privileges means that you have to use them responsibly and that you protect them from attackers.

You don't want your account/name in the logs and security incident summary report for the major breach that cost the organization X million of dollars.

…and you REALLY don't want one of your actions to be THE reason the attackers got to business-critical assets (e.g. logging onto a BYOD device with Domain/Enterprise/Global or AWS Account admin led to ransomware/encryption/extortion of the organization).

The principle of least privilege helps protect YOU as well as the overall organization. You can learn more about securing privileged access at https://aka.ms/SPA