Tag Archives: ask the experts

When the Security Control Plane Fails: Build a Minimum Viable Defensive System

Posted on by
Reply

At 2:13 a.m., the SOC receives an alert involving a cloud administrator.

At 2:16, analysts lose access to the SIEM because authentication depends on the identity provider now under investigation.

At 2:19, the incident collaboration channel disappears.

At 2:23, the on-call engineer discovers that the break-glass credentials are stored in the privileged-access platform—which also authenticates through the suspect identity provider.

At 2:27, the cloud console still shows green status indicators, but nobody can establish whether the logs are complete, delayed, or manipulated.

By 2:35, the organization has two incidents.

The first is the security event.

The second is the loss of its ability to respond to the security event.

That second incident is the one most response plans do not adequately address.

3Errors

Incident Response Has a Hidden Assumption

Most incident-response plans assume the defensive machinery will survive the incident.

The identity provider will authenticate responders. The privileged-access system will issue administrative credentials. The cloud management plane will accept containment commands. The SIEM will provide reliable telemetry. The ticketing platform will maintain the timeline. Email, chat, conferencing, and document-sharing systems will allow the response team to coordinate.

Those systems are treated as infrastructure surrounding the incident rather than as potential components of the incident.

That is a dangerous assumption.

In a recent State of Security post, I argued that controls that look separate on an architecture diagram may actually be “branches of the same tree.” They may share an identity provider, administrative tenant, logging pipeline, automation layer, DNS infrastructure, certificate authority, or cloud control plane. When one of those shared foundations fails, several supposedly independent controls can fail with it. (State of Security)

The next question is harder:

What is the smallest defensive system the organization must be able to operate after that tree falls?

This is not conventional disaster recovery. It is not simply a matter of restoring the SIEM, activating a backup tenant, or retrieving an emergency password.

It is degraded-mode security operations.

The Control Plane Can Fail by Lying

Security teams usually test failures as availability problems.

The identity provider is down. The SIEM is unreachable. The ticketing platform will not load. The primary cloud region is unavailable.

Those are relatively clean failures. They are visible, bounded, and easy to describe during a tabletop exercise.

Adversarial failure is different.

A compromised identity provider may continue issuing tokens. A hostile administrator may alter conditional-access policies while leaving the service operational. A logging pipeline may continue displaying data while silently omitting selected events. A collaboration platform may preserve most messages while exposing the incident channel to the attacker. An automation platform may continue executing containment playbooks after its credentials or logic have been subverted.

The system is not down.

It is lying.

That distinction changes the recovery problem. An unavailable system can sometimes be restored. An untrustworthy system must first be excluded from the response path.

NIST’s cyber-resiliency work provides the right foundation for thinking about this. It frames resiliency around four outcomes: anticipating adverse conditions, withstanding them, recovering from them, and adapting afterward. It also applies that thinking to shared services, common infrastructure, and systems of systems—not merely individual applications. (NIST Computer Security Resource Center)

A resilient security program therefore cannot define success only as preventing compromise or restoring systems. It must be able to continue essential defensive operations while some of its own systems are unavailable, degraded, or hostile.

Start With Inversion

The normal planning question is:

How do we keep the security control plane available?

That is necessary, but incomplete.

Invert the problem:

Assume the primary security control plane is unavailable or cannot be trusted. How do we still defend the organization?

Assume that:

  • The primary identity provider cannot be trusted.

  • Existing administrative sessions may belong to the attacker.

  • The privileged-access platform is inaccessible.

  • Centralized telemetry is incomplete.

  • Normal collaboration and ticketing systems are exposed.

  • Managed responder workstations may be under hostile administrative control.

  • Cloud automation may be executing unauthorized changes.

  • DNS, certificate, key-management, or time services may be unreliable.

  • One or more key responders cannot be reached.

Now ask what responders must still be able to do.

Not which products must be restored.

Not which dashboards executives expect to see.

Not which recovery checklist should be opened first.

What capabilities must exist for the organization to remain defensible?

Define the Minimum Viable Defensive System

A Minimum Viable Defensive System is the smallest deliberately independent collection of people, authority, identities, devices, communications, telemetry, containment mechanisms, evidence storage, and recovery materials that allows the organization to continue defending itself when its normal security control plane is unavailable or untrusted.

It is not a second full-sized SOC.

It is not a duplicate of every production security tool.

It is not a collection of individually labeled “break-glass” features.

It is a composed operating system for degraded defense.

At minimum, it must provide six capabilities.

Capability Minimum viable state Evidence that it is independent
Authenticate Authorized responders can establish identity and emergency authority using protected credentials and trusted administrative devices. The path does not require the primary identity provider, PAM platform, corporate network, normal endpoint-management plane, or primary email account.
Communicate and coordinate Responders can establish a secure command channel, assign roles, reach critical internal and external parties, and maintain a decision and action log. Accounts, provider, authentication, network path, and recovery information do not depend on the primary collaboration environment.
Observe Responders can obtain trustworthy information from critical systems and identify gaps, delay, or tampering in normal telemetry. Collection, storage, access, keys, and administrative authority do not all share the suspected failure domain.
Contain Responders can revoke access, disable identities, isolate assets, stop dangerous automation, alter routes or policies, and protect critical systems. Emergency containment does not require normal SSO, normal PAM approval, the primary SOAR platform, or access to the normal ticketing workflow.
Preserve evidence Responders can store relevant logs, configuration data, images, exports, notes, and decision records with integrity and provenance. Primary administrators cannot silently alter or delete the evidence, and responders retain access to keys, timestamps, capacity, and custody procedures.
Reconstitute Responders can rebuild roots of trust and restore defensive services from known-good materials in a defined order. Configurations, credentials, keys, backups, tooling, and administrative access do not depend entirely on the environment being rebuilt.

These are capabilities, not products.

A security team may satisfy them through a mixture of cloud-native controls, offline materials, separate accounts, alternative providers, clean devices, manual procedures, direct system access, and preauthorized decision rights.

NIST makes a similar architectural point in its resiliency guidance: survivability comes from combinations of technology, architectural choices, engineering practices, operational procedures, and people—not from one product or control.

Break Glass Is Not an Account

Organizations often point to an emergency administrative account as proof that degraded-mode access has been addressed.

That is only one link in the chain.

Consider an emergency account that:

  • Is stored in the normal PAM platform.

  • Uses the normal identity provider for authentication.

  • Requires a managed laptop that cannot be unlocked without normal SSO.

  • Can be used only from the corporate network.

  • Depends on the normal DNS and certificate infrastructure.

  • Requires an approval recorded in the normal ticketing system.

  • Sends its alerts to the normal SOC mailbox.

The account exists.

The emergency capability does not.

Break glass is not an account. It is an end-to-end operating path.

Microsoft’s emergency-access guidance recommends multiple cloud-only accounts, authentication methods that differ from normal administrative authentication, secure storage, monitoring, and recurring validation. AWS similarly describes pre-created emergency identities and roles, dedicated emergency access arrangements, hardware authentication, and periodic testing for situations in which the centralized identity provider is unavailable or compromised. (Microsoft Learn)

Those are valuable design ingredients. The security program still has to compose them into a functioning response system.

The responder must be able to retrieve the credential, authenticate, use a trusted device, reach the management interface, execute an authorized action, record that action, observe its effect, and preserve the resulting evidence.

Testing only the login proves only the login.

Independence Is a Property of the Whole Path

Two tools can be different and still fail together.

A secondary messaging platform is not independent if it uses the same identity provider.

A backup SIEM is not independent if it receives data through the same collectors.

A separate cloud account is not independent if the compromised organization administrator can assume control over it.

An immutable log store is not useful during the incident if access to its decryption keys depends on the failed key-management plane.

A responder laptop is not clean if it must contact the suspect device-management service before allowing an administrator to sign in.

An alternate network path is not alternate if it converges on the same DNS, certificate, firewall-management, or telecommunications dependency.

This is why fallback design must be scenario-specific. Nothing is universally independent. It is independent only relative to a defined failure.

NIST’s guidance on diversity and redundancy warns that apparent alternatives can converge on the same underlying foundation. It specifically treats diversity of command, control, and communications paths—including out-of-band paths—as a resiliency technique, and notes that redundancy can be undermined when duplicated capabilities share common resources or homogeneous components.

CISA guidance has likewise emphasized out-of-band incident communications, separate management paths, and logging aggregated into protected out-of-band locations. These practices reduce the chance that the compromised environment can blind or isolate the response team. (CISA)

Again, those mechanisms are necessary.

They are not sufficient until they work together.

Restore Capabilities, Not Products

During a compound failure, organizations tend to restore whatever system has the most visible outage, the loudest executive sponsor, or the clearest recovery runbook.

That can produce the wrong order.

The goal is not to make the security stack look normal as quickly as possible. The goal is to restore trustworthy defensive agency.

A practical priority sequence looks like this.

1. Establish trusted command

The organization needs an incident commander, an emergency authority model, authenticated responders, a protected communications channel, and a functioning decision record.

Without trusted command, every subsequent action is debatable. Responders do not know who is authorized, which instructions are legitimate, or whether the attacker is participating in the response.

This layer should also provide access to an offline or separately protected contact roster covering executives, legal counsel, insurers, outside responders, critical vendors, law enforcement contacts, and communications personnel.

2. Establish a trustworthy view

Responders must determine what they can still observe and which sources remain credible.

This does not require immediately rebuilding the entire SIEM. It may involve direct access to native audit sources, an independently protected log archive, network telemetry, cloud snapshots, system exports, or read-only queries through emergency accounts.

The first question is not, “Are logs arriving?”

It is, “What evidence do we have that these logs are complete, current, and resistant to alteration by the suspected adversary?”

Evidence preservation begins here. Observation and preservation should not be separated into distant phases. The data available during the first hour may not remain available later.

3. Regain safe containment capability

Once responders have enough confidence to act, they need a limited but reliable way to constrain the event.

That may include:

  • Revoking sessions and tokens.

  • Disabling identities.

  • Isolating accounts, workloads, subscriptions, or network segments.

  • Blocking known infrastructure.

  • Suspending compromised automation.

  • Protecting backups and logging repositories.

  • Restricting administrative paths.

  • Moving critical services into a predefined defensive posture.

Containment paths should be narrow, preauthorized, observable, and reversible where practical.

They should not depend on the same orchestration layer whose trust is in question.

4. Reconstitute roots of trust

Only after responders have trusted command, sufficient visibility, and safe agency should they begin rebuilding the normal control plane.

Reconstitution must follow dependency order.

Identity may need to be restored before PAM. Key management may need to be restored before protected logging. Trusted administrative endpoints may need to be rebuilt before cloud policy is changed. Logging may need to be reestablished before production workloads are reconnected.

Restoring dependent tools before their foundations are trustworthy creates the appearance of recovery without its substance.

This is a priority model, not a waterfall. Observation, evidence preservation, and containment will often proceed in parallel. The point is to prevent teams from restoring familiar products while critical defensive capabilities remain absent.

Measure Time to Defensible State

Traditional recovery planning uses recovery-time objectives to express how long a system can remain in recovery before unacceptable harm occurs. That is useful for determining when an identity platform, logging service, or collaboration system must return. (NIST Computer Security Resource Center)

It does not answer what defenders can do while those systems remain unavailable.

A security program should add another measure:

Time to Defensible State

Time to Defensible State is the elapsed time between declaring the primary defensive control plane unavailable or untrustworthy and validating that the Minimum Viable Defensive System is operating through independent paths.

A defensible state might require proof that:

  • Emergency authority has been invoked.

  • Required responders have authenticated independently.

  • A secure command channel is operating.

  • A decision and action record is being maintained.

  • At least one trustworthy telemetry path is available.

  • Responders can execute and verify an emergency containment action.

  • Evidence can be deposited into an independently protected repository.

  • The team understands which normal services remain prohibited.

“Someone successfully logged in” is not a defensible state.

“We opened the backup chat room” is not a defensible state.

The state is reached only when the capabilities operate together.

Organizations should measure the component times as well:

  • Time to recognize and declare control-plane degradation.

  • Time to establish trusted responder identity.

  • Time to establish out-of-band command.

  • Time to obtain the first trustworthy telemetry.

  • Time to execute the first validated containment action.

  • Time to preserve the first evidentiary artifact.

  • Time to begin controlled reconstitution.

  • Maximum duration the degraded system can operate.

That last measure matters.

A fallback that works for 20 minutes but cannot support a twelve-hour investigation is not sufficient. Capacity, credential lifetime, battery life, communications access, evidence-storage volume, staffing, vendor support, and shift turnover are all part of the design.

Test Compound Failure, Not Components

Most organizations test their emergency mechanisms one at a time.

The emergency administrator logs in.

The backup conference bridge works.

The log archive accepts a test event.

The incident-response binder opens.

The cloud backup restores.

Every component passes.

Then the system fails during the exercise because nobody can retrieve the emergency credential without the PAM system, the clean laptop requires the unavailable identity provider, and the alternate communications channel does not include legal counsel or the cloud team.

Component success is not system success.

A meaningful exercise should begin with a compound condition such as:

The identity provider is suspected of compromise. Existing administrative sessions cannot be trusted. The centralized logging query plane is unavailable, although some collection continues. Normal email, chat, ticketing, and PAM systems are prohibited. The cloud management environment may contain unauthorized policy changes.

Then make the team perform the work.

Retrieve the emergency materials using the real custody process.

Start the designated administrative devices.

Use the actual alternate network path.

Authenticate to the necessary systems.

Generate a known event and prove it appears in the independent telemetry path.

Contain a sacrificial asset.

Preserve an artifact and validate its integrity.

Reach an external participant.

Maintain the incident log.

Operate long enough to perform a shift handoff.

Exit degraded mode, reconcile all emergency actions, rotate credentials, and restore monitoring.

Do not allow the exercise controller to hand the team imaginary access, pretend that a credential was retrieved, or declare a containment action successful without executing a safe equivalent.

Every simulated shortcut conceals a dependency.

NIST’s current incident-response guidance treats preparation, response, and recovery as integrated parts of cybersecurity risk management rather than as a separate binder activated after detection. Compound-failure testing is one way to turn that integration into operational evidence. (NIST Computer Security Resource Center)

The Fallback Creates Its Own Risk

An independent defensive system is powerful.

That also makes it dangerous.

Emergency identities may hold standing privilege. Alternative communications channels may escape normal monitoring. Offline credentials can become stale or be mishandled. Direct administrative paths can bypass approval systems. Separate evidence stores may contain highly sensitive information. Dormant devices may miss critical patches.

The fallback cannot simply be hidden and forgotten.

It requires its own controls:

  • Dual custody for the most powerful emergency materials.

  • Tamper-evident storage and access records.

  • Narrowly scoped emergency roles.

  • Independent monitoring of every activation.

  • Regular credential, key, and device validation.

  • Immediate review and rotation after use.

  • Defined activation and termination authority.

  • Reconciliation of emergency actions into normal records.

  • Periodic review for new shared dependencies.

This is a second-order tradeoff.

The organization creates exceptional access to survive the loss of normal access controls. It must then protect that exceptional access without reconnecting it to the same control plane it was designed to bypass.

There is no product setting that resolves that tension. It must be engineered and governed.

A Practical Design Standard

A security program should not claim degraded-mode readiness until it can produce six things.

1. A declared defensive minimum

The organization has explicitly defined what authentication, communication, observation, containment, evidence preservation, and reconstitution mean in its environment.

2. A dependency topology

Each capability has been traced through its identities, devices, networks, providers, administrators, keys, data sources, and human custodians.

Shared failure domains are visible.

3. Independence claims tied to scenarios

The organization does not say that a system is simply “independent.” It states which failures it is independent from and provides evidence supporting that claim.

4. Activation and exit criteria

Responders know who can declare the primary control plane untrusted, what changes when that declaration occurs, and what evidence is required before normal systems can be used again.

5. Measured recovery of defensive capability

The organization has established a target Time to Defensible State and measured it during an end-to-end exercise.

6. Evidence of sustained operation

The fallback has demonstrated that it can support a realistic incident duration, including staffing changes, evidence growth, credential use, containment actions, external coordination, and eventual reconciliation.

This turns degraded-mode response from a collection of reassuring statements into a testable design standard.

Small. Separate. Boring. Measured.

The Minimum Viable Defensive System should be small enough to understand.

It should be separate enough to survive the named failure.

It should be boring enough to operate under stress.

It should be measured often enough that leadership knows whether it is real.

Centralization is not inherently bad. Modern security programs need centralized identity, logging, administration, orchestration, and collaboration.

But centralized efficiency creates concentrated dependency.

A mature program does not pretend those dependencies will always survive. It plans for the moment when the normal tools are unavailable, the dashboards are questionable, and the attacker may be using the same administrative machinery as the defenders.

The question is no longer:

Do we have break-glass accounts?

The question is:

Can we prove that authorized responders can authenticate, communicate, observe, contain, preserve evidence, and begin reconstitution when the primary security control plane is unavailable or hostile—and can they do it within a measured period?

Until the answer is yes, the organization is resilient only while its assumptions hold.

Security programs must do more than defend the business.

They must remain capable of defending it while their own machinery is failing.

More Information and Assistance

MicroSolved, Inc. can help organizations:

  • Map security-control dependencies and shared failure domains.

  • Define a Minimum Viable Defensive System.

  • Design independent emergency identity, communications, administrative, logging, and evidence paths.

  • Establish degraded-mode activation and recovery procedures.

  • Run compound-failure tabletop and live validation exercises.

  • Define and measure Time to Defensible State.

Contact MicroSolved at info@microsolved.com or +1.614.351.1237. Relax. We’re on watch. 

* AI tools were used as a research assistant for this content, but human moderation and writing are also included. The included images are AI-generated.

AI in Cyber Defense: What Works Today vs. What’s Hype

Posted on by
Reply

Practical Deployment Paths

Artificial Intelligence is no longer a futuristic buzzword in cybersecurity — it’s here, and defenders are being pressured on all sides: vendors pushing “AI‑enabled everything,” adversaries weaponizing generative models, and security teams trying to sort signal from noise. But the truth matters: mature security teams need clarity, realism, and practicable steps, not marketing claims or theoretical whitepapers that never leave the lab.

The Pain Point: Noise > Signal

Security teams are drowning in bold AI vendor claims, inflated promises of autonomous SOCs, and feature lists that promise effortless detection, response, and orchestration. Yet:

  • Budgets are tight.

  • Societies face increasing threats.

  • Teams lack measurable ROI from expensive, under‑deployed proof‑of‑concepts.

What’s missing is a clear taxonomy of what actually works today — and how to implement it in a way that yields measurable value, with metrics security leaders can trust.

AISecImage

The Reality Check: AI Works — But Not Magically

It’s useful to start with a grounding observation: AI isn’t a magic wand.
When applied properly, it does elevate security outcomes, but only with purposeful integration into existing workflows.

Across the industry, practical AI applications today fall into a few consistent categories where benefits are real and demonstrable:

1. Detection and Triage

AI and machine learning are excellent at analyzing massive datasets to identify patterns and anomalies across logs, endpoint telemetry, and network traffic — far outperforming manual review at scale. This reduces alert noise and helps prioritize real threats. 

Practical deployment path:

  • Integrate AI‑enhanced analytics into your SIEM/XDR.

  • Focus first on anomaly detection and false‑positive reduction — not instant response automation.

Success metrics to track:

  • False positive rate reduction

  • Mean Time to Detect (MTTD)

2. Automated Triage & Enrichment

AI can enrich alerts with contextual data (asset criticality, identity context, threat intelligence) and triage them so analysts spend time on real incidents. 

Practical deployment path:

  • Connect your AI engine to log sources and enrichment feeds.

  • Start with automated triage and enrichment before automation of response.

Success metrics to track:

  • Alerts escalated vs alerts suppressed

  • Analyst workload reduction

3. Accelerated Incident Response Workflows

AI can power playbooks that automate parts of incident handling — not the entire response — such as containment, enrichment, or scripted remediation tasks. 

Practical deployment path:

  • Build modular SOAR playbooks that call AI models for specific tasks, not full control.

  • Always keep a human‑in‑the‑loop for high‑impact decisions.

Success metrics to track:

  • Reduced Mean Time to Respond (MTTR)

  • Accuracy of automated actions

What’s Hype (or Premature)?

While some applications are working today, others are still aspirational or speculative:

❌ Fully Autonomous SOCs

Vendor claims of SOC teams run entirely by AI that needs minimal human oversight are overblown at present. AI excels at assistance, not autonomous defense decision‑making without human‑in‑the‑loop review. 

❌ Predictive AI That “Anticipates All Attacks”

There are promising approaches in predictive analytics, but true prediction of unknown attacks with high fidelity is still research‑oriented. Real‑world deployments rarely provide reliable predictive control without heavy contextual tuning. 

❌ AI Agents With Full Control Over Remediations

Agentic AI — systems that take initiative across environments — are an exciting frontier, but their use in live environments remains early and risk‑laden. Expectations about autonomous agents running response workflows without strict guardrails are unrealistic (and risky). 

A Practical AI Use Case Taxonomy

A clear taxonomy helps differentiate today’s practical uses from tomorrow’s hype. Here’s a simple breakdown:

Category What Works Today Implementation Maturity
Detection Anomaly/Pattern detection in logs & network Mature
Triage & Enrichment Alert prioritization & context enrichment Mature
Automation Assistance Scripted, human‑supervised response tasks Growing
Predictive Intelligence Early insights, threat trend forecasting Emerging
Autonomous Defense Agents Research & controlled pilot only Experimental

Deployment Playbooks for 3 Practical Use Cases

1️⃣ AI‑Enhanced Log Triage

  • Objective: Reduce analyst time spent chasing false positives.

  • Steps:

    1. Integrate machine learning models into SIEM/XDR.

    2. Tune models on historical data.

    3. Establish feedback loops so analysts refine model behaviors.

  • Key metric: ROC curve for alert accuracy over time.

2️⃣ Phishing Detection & Response

  • Objective: Catch sophisticated phishing that signature engines miss.

  • Steps:

    1. Deploy NLP‑based scanning on inbound email streams.

    2. Integrate with threat intelligence and URL reputation sources.

    3. Automate quarantine actions with human review.

  • Key metric: Reduction in phishing click‑throughs or simulated phishing failure rates.

3️⃣ SOAR‑Augmented Incident Response

  • Objective: Speed incident handling with reliable automation segments.

  • Steps:

    1. Define response playbooks for containment and enrichment.

    2. Integrate AI for contextual enrichment and prioritization.

    3. Ensure manual checkpoints before broad remediation actions.

  • Key metric: MTTR before/after SOAR‑AI implementation.

Success Metrics That Actually Matter

To beat the hype, track metrics that tie back to business outcomes, not vendor marketing claims:

  • MTTD (Mean Time to Detect)

  • MTTR (Mean Time to Respond)

  • False Positive/Negative Rates

  • Analyst Productivity Gains

  • Time Saved in Triage & Enrichment

Lessons from AI Deployment Failures

Across the industry, failed AI deployments often stem from:

  • Poor data quality: Garbage in, garbage out. AI needs clean, normalized, enriched data. 

  • Lack of guardrails: Deploying AI without human checkpoints breeds costly mistakes.

  • Ambiguous success criteria: Projects without business‑aligned ROI metrics rarely survive.

Conclusion: AI Is an Accelerator, Not a Replacement

AI isn’t a threat to jobs — it’s a force multiplier when responsibly integrated. Teams that succeed treat AI as a partner in routine tasks, not an oracle or autonomous commander. With well‑scoped deployment paths, clear success metrics, and human‑in‑the‑loop guardrails, AI can deliver real, measurable benefits today — even as the field continues to evolve.

 

* AI tools were used as a research assistant for this content, but human moderation and writing are also included. The included images are AI-generated.

Identity Security Is Now the #1 Attack Vector — and Most Organizations Are Not Architected for It

Posted on by
Reply

How identity became the new perimeter

In 2025, identity is no longer simply a control at the edge of your network — it is the perimeter. As organizations adopt SaaS‑first strategies, hybrid work, remote access, and cloud identity federation, the traditional notion of network perimeter has collapsed. What remains is the identity layer — and attackers know it.

Today’s breaches often don’t involve malware, brute‑force password cracking, or noisy exploits. Instead, adversaries leverage stolen tokens, hijacked sessions, and compromised identity‑provider (IdP) infrastructure — all while appearing as legitimate users.

SyntheticID

That shift makes identity security not just another checkbox — but the foundation of enterprise defense.

Failure points of modern identity stacks

Even organizations that have deployed defenses like multi‑factor authentication (MFA), single sign‑on (SSO), and conditional access policies often remain vulnerable. Why? Because many identity architectures are:

  • Overly permissive — long‑lived tokens, excessive scopes, and flat permissioning.

  • Fragmented — identity data is scattered across IdPs, directories, cloud apps, and shadow IT.

  • Blind to session risk — session tokens are often unmonitored, allowing token theft and session hijacking to go unnoticed.

  • Incompatible with modern infrastructure — legacy IAMs often can’t handle dynamic, cloud-native, or hybrid environments.

In short: you can check off MFA, SSO, and PAM, and still be wide open to identity‑based compromise.

Token‑based attack: A walkthrough

Consider this realistic scenario:

  1. An employee logs in using SSO. The browser receives a token (OAuth or session cookie).

  2. A phishing attack — or adversary-in-the-middle (AiTM) — captures that token after the user completes MFA.

  3. The attacker imports the token into their browser and now impersonates the user — bypassing MFA.

  4. The attacker explores internal SaaS tools, installs backdoor OAuth apps, and escalates privileges — all without tripping alarms.

A single stolen token can unlock everything.

Building identity security from first principles

The modern identity stack must be redesigned around the realities of today’s attacks:

  • Identity is the perimeter — access should flow through hardened, monitored, and policy-enforced IdPs.

  • Session analytics is a must — don’t just authenticate at login. Monitor behavior continuously throughout the session.

  • Token lifecycle control — enforce short token lifetimes, minimize scopes, and revoke unused sessions immediately.

  • Unify the view — consolidate visibility across all human and machine identities, across SaaS and cloud.

How to secure identity for SaaS-first orgs

For SaaS-heavy and hybrid-cloud organizations, these practices are key:

  • Use a secure, enterprise-grade IdP

  • Implement phishing-resistant MFA (e.g., hardware keys, passkeys)

  • Enforce context-aware access policies

  • Monitor and analyze every identity session in real time

  • Treat machine identities as equal in risk and value to human users

Blueprint: continuous identity hygiene

Use systems thinking to model identity as an interconnected ecosystem:

  • Pareto principle — 20% of misconfigurations lead to 80% of breaches.

  • Inversion — map how you would attack your identity infrastructure.

  • Compounding — small permissions or weak tokens can escalate rapidly.

Core practices:

  • Short-lived tokens and ephemeral access

  • Just-in-time and least privilege permissions

  • Session monitoring and token revocation pipelines

  • OAuth and SSO app inventory and control

  • Unified identity visibility across environments

30‑Day Identity Rationalization Action Plan

Day Action
1–3 Inventory all identities — human, machine, and service.
4–7 Harden your IdP; audit key management.
8–14 Enforce phishing-resistant MFA organization-wide.
15–18 Apply risk-based access policies.
19–22 Revoke stale or long-lived tokens.
23–26 Deploy session monitoring and anomaly detection.
27–30 Audit and rationalize privileges and unused accounts.

More Information

If you’re unsure where to start, ask these questions:

  • How many active OAuth grants are in our environment?

  • Are we monitoring session behavior after login?

  • When was the last identity privilege audit performed?

  • Can we detect token theft in real time?

If any of those are difficult to answer — you’re not alone. Most organizations aren’t architected to handle identity as the new perimeter. But the gap between today’s risks and tomorrow’s solutions is closing fast — and the time to address it is now.

Help from MicroSolved, Inc.

At MicroSolved, Inc., we’ve helped organizations evolve their identity security models for more than 30 years. Our experts can:

  • Audit your current identity architecture and token hygiene

  • Map identity-related escalation paths

  • Deploy behavioral identity monitoring and continuous session analytics

  • Coach your team on modern IAM design principles

  • Build a 90-day roadmap for secure, unified identity operations

Let’s work together to harden identity before it becomes your organization’s softest target. Contact us at microsolved.com to start your identity security assessment.

References

  1. BankInfoSecurity – “Identity Under Siege: Enterprises Are Feeling It”

  2. SecurityReviewMag – “Identity Security in 2025”

  3. CyberArk – “Lurking Threats in Post-Authentication Sessions”

  4. Kaseya – “What Is Token Theft?”

  5. CrowdStrike – “Identity Attacks in the Wild”

  6. Wing Security – “How to Minimize Identity-Based Attacks in SaaS”

  7. SentinelOne – “Identity Provider Security”

  8. Thales Group – “What Is Identity Security?”

  9. System4u – “Identity Security in 2025: What’s Evolving?”

  10. DoControl – “How to Stop Compromised Account Attacks in SaaS”

 

* AI tools were used as a research assistant for this content, but human moderation and writing are also included. The included images are AI-generated.

Ask The Experts: Favorite HoneyPoint Component

Posted on by
Reply

This time around, we got a question from a client where HoneyPoint was being demoed for the experts.

Q: “What is your favorite component of HoneyPoint and why? How have you used it to catch the bad guys?”

Jim Klun started off with:

My favorite component is the simplest: HoneyPoint Agent. 

It’s ease of deployment and the simple fact that all alerts from an agent are of note – someone really did touch an internal service on a box where no such service legitimately exists – makes it attractive. 
No one will argue with you about meaning. 

I have recently seen it detect a new MSSQL worm (TCP 1433) within a large enterprise – information obtained from my own laptop. The Agent I had deployed on the laptop had a 1433 listener. It captured the payload from an attacking desktop box located in an office in another US state. 

The HoneyPoint Agent info was relayed to a corporate team that managed a global IPS. They confirmed the event and immediately updated their IPS that was – ideally – protecting several hundred thousand internal machines from attack. 

Honeypoint Agent: It’s simple, it works.

Adam Hostetler added his view:

I’m a simple, no frills guy, so I just like the regular old TCP listener component built into Agent. We have stood these up on many engagements and onsite visits and picked up unexpected traffic. Sometimes malware, sometimes a misconfiguration, or sometimes something innocuous (inventory management). I also find it useful for research by exposing it to the Internet.

John Davis closed with a different view:

My favorite HoneyPoint is Wasp. Watching how skilled attackers actually compromise whole networks by initially compromising one user machine gives me the shivers! Especially since most networks we see aren’t properly enclaved and monitored. If I were a CISO, knowing what is on my network at all times would be of primary importance; including what is going on on the client side! Wasp gets you that visibility and without all the traditional overhead and complexity of other end-point monitoring and white listing tools.

Have a question about HoneyPoint? Want to talk about your favorite component or use case scenario? Hit us on Twitter (@lbhuston or @microsolved). We can’t wait to hear from you. Feel free to send us your question for the experts. Readers whose questions we pick for the blog get a little surprise for their contribution. As always, thanks for reading and stay safe out there! 

Ask The Experts: New Device Check Lists

Posted on by
2

This time around on Ask The Experts, we have a question from a reader and it got some great responses from the team:

 

Q: “I need a quick 10 item or less checklist that I can apply to new devices when my company wants to put them on our network. What kinds of things should I do before they get deployed and are in use around the company?”

 

Bill Hagestad started us off with:

The Top 10 checklist items a CISO/or equivalent authority should effectively manage before installing, configuring and managing new devices on a network includes the following;

 

1)Organize your staff and prepare them for the overall task of documenting and diagramming your network infrastructure – give them your commander’s network management intent;

2)Create a physical and logical network map – encourage feedback from your team regarding placement of new hardware and software;

3)Use industry standards for your network including physical and logical security, take a good look at NIST Special Publication SP 800-XX Series;

4)Make certain that you and your team are aware of the requisite compliance standards for your business and industry, it will help to ensure you are within legal guidelines before installing new devices or perhaps you may discover the hardware or software you are considering isn’t necessary after all;

5)Ensure that after you have created the necessary network maps for your infrastructure in Step 2) above, conduct a through inventory of all infrastructure which is both critical and important to your business, then document this baseline;

6)Create a hardware/software configuration change procedure; or if you already have his inlace, have your team review it for accuracy; make certain everyone on the team knows to document all changes/moves/additions on the network;

7)Focus not only on the correlation of newly implemented devices on the internal networks but also look at the dependencies and effects on external infrastructure such as voice/data networks – nothing worse than making an internal change to your network and having your Internet go down unnecessarily;

8)Ensure that new network devices being considered integrate gracefully into your existing logging and alerting mechanisms; no need to install something new only to have to recreate the proverbial wheel in order to monitor it;

9)Consider the second & third order effects of newly installed devices on the infrastructure and their potential impact on remote workers and mobile devices used on the network;

10)Install HoneyPoint Security Server (HPSS) to agentlessly & seamlessly monitor external and potential internal threats to your newly configured network….

 

Of course a very authoritative guide is published by the national Security Agency called appropriately “Manageable Network Plan” and available for download @:

 

http://www.nsa.gov/ia/_files/vtechrep/ManageableNetworkPlan.pdf


Jim Klun added:

1. Make sure the device is necessary and not just a whim on the part of management.   Explain that each new device increases risk. 

2. If the device’s function can be performed by an existing internal service, use that service instead. 

3. Inventory new devices by name, IP addresses, function and – most importantly – owners.  There should be a device owner and a business owner who can verify continued need for the device.  Email those owners regularly,   querying them about continued need. Make sure that these folks have an acknowledged role to support the application running on the devices and are accountable for its security. 

4. Research the device and the application(s) its support.  Have no black boxes in your datacenter.  Include an abstract of this in the inventory. 

5. Make sure a maintenance program is in place – hold the app and device owner accountable. 

6. Do a security audit of the device wehn fully configured. Hit it with vulnerability scanners and make sure that this happens at least quarterly. 

7. Make sure monitoring is in place and make very sure all support staff are aware of the device and any alerts it may generate. Do not blind-side the operations staff. 

8. If the device can log its activities ( system and application ) to a central log repository, ensure that happens as part of deployment. 

9. Make sure the device is properly placed in your network architecture. Internet-exposed systems should be isolated in an Internet DMZ.  Systems holding sensitive data should similarly be isolated. 

10. Restrict access to the device as narrowly as possible. 

 

Finally.. if you can, for every device in your environment, log its network traffic and create a summary of what is “normal” for that device.  

Your first indication of a compromise is often a change in the way a system “talks”. 

 

Adam Hostetler chimed in with: 

Will vary a lot depending on device, but here are some suggestions

 

1. Ensure any default values are changed. Passwords, SNMP strings, wireless settings etc.

2. Disable any unnecessary services

3. Ensure it’s running the latest firmware/OS/software

4. Add the device to your inventory/map, catalog MAC address, owner/admin, etc.

5. Perform a small risk assessment on the device. What kind of risk does it introduce to your environment? Is it worth it?

6. Test and update the device in a separate dev segment, if you have one.

7. Make sure the device fits in with corporate usage policies

8. Perform a vulnerability assessment against the device. 

9. Search the internet for any known issues, vulnerabilities or exploits that might effect the device.

  1. Configure the device to send logs to your logging server or SEIM, if you have one.

 

And John Davis got the last word by adding: 

From a risk management perspective, the most important thing a CISO needs to ensure is in place before new devices are implemented on the network is a formal, documented Systems Development Life Cycle or Change Management program. Having such a program in place means that all changes to the system are planned and documented, that security requirements and risk have been assessed before devices have purchased and installed, that system configuration and maintenance issues have been addressed, that the new devices are included in business continuity planning, that proper testing of devices (before and after implementation on the network) is undertaken and more. If a good SDLC/Change Management program is not in place, CISOs should ensure that development and implementation of the program is given a high priority among the tasks they wish to accomplish.

 

Whew, that was a great question and there is some amazing advice here from the experts! Thanks for reading, and until next time, stay safe out there! 

 

Got a question for the experts? Give us a shout on Twitter (@microsolved or @lbhuston) and we’ll base a column on your questions!

Ask The Experts: Too Much Data

Posted on by
2

Q: “I have massive amounts of log files I have to dig through every day. I have tried a full blown SEIM, but can’t get it to work right or my management to support it with budget. Right now I have Windows logs, firewall logs and AV logs going to a syslog server. That gives me a huge set of text files every day. How can I make sense of all that text? What tools and processes do you suggest? What should I be looking for? HELP!!!!”

 

Adam Hostetler answered with:

 

I would say give OSSEC a try. It’s a free log analyzer/SEIM. It doesn’t

have a GUI with100 different dashboards and graphs, it’s all cli and

e-mail based (though there is a simple web interface for it also). It is

easy to write rules for, and it has default rules for many things,

except for your AV. You can write simple rules for that, especially if

you are just looking for items AV caught. It does take some tuning, as

with all analysis tools, but isn’t difficult after learning how OSSEC

works. If you want to step it up a bit, you can feed OSSEC alerts into

Splunk where you can trend alerts, or create other rules and reports in it.

 

Bill Hagestad added:

 

First things first – don’t be or feel overwhelmed – log files are what they are much disparate data from a variety of resources that need reviewing sooner rather than later.

 

Rather than looking at another new set to tools or the latest software gizmo the trade rags might suggest based on the flair of the month, try a much different and more effective approach to the potential threat surface to your network and enterprise information network.

 

First take a look at what resources need to be protected in order of importance to your business. Once you have prioritized these assets then begin to  determine what is the minimum level of acceptable risk you can assign to each resource you have just prioritized.

 

Next, make two columns on a either a piece of paper or a white board. In one column list your resources in order of protection requirements, i.e.; servers with customer data, servers with intellectual property, so and so forth. In a column to the right of the first assets list plug in your varying assigned levels of risk. Soon you will see what areas/assets within your organization/enterprise you should pay the most attention to in terms of threat mitigation.

 

After you have taken the steps to determine your own self- assessment of risk contact MicroSolved for both a vulnerability assessment and penetration test to provide additional objective perspective on threats to your IT infrastructure and commercial enterprise. 

 

Finally, Jim Klun weighed in with: 

 

You are way ahead of the game by just having a central log repository.  You can go to one server and look back in time to the point where you expect a security incident.

 

And what you have – Windows logs, firewall logs, and AV – is fantastic.  Make sure all your apps are logging as well ( logon success, logon failure).

Too often I have seen apps attacked and all I had in syslog was OS events that showed nothing.

 

Adam’s suggestion, OSSEC, is the way to go to keep cost down… but don’t just install and hope for the best.

You will have to tweak the OSSEC rules and come up with what works.

 

Here’s the rub: there is no substitute for knowing your logs – in their raw format, not pre-digested by a commercial SIEM or OSSEC.

 

That can seem overwhelming. And to that, some Unix commands and regular expressions are your friend.

 

So:

 

zcat auth.log | grep ssh | egrep -i ‘failed|accepted’

 

produces:

 

Jul  4 16:32:16 dmz-server01 sshd[8786]: Failed password for user02 from 192.168.105.51 port 38143 ssh2

Jul  4 16:33:53 dmz-server01 sshd[8786]: Accepted password for user01 from 192.168.105.38 port 38143 ssh2

Jul  4 16:36:05 dmz-server01 sshd[9010]: Accepted password for user01 from 192.168.105.38 port 38315 ssh2

Jul  5 01:04:00 dmz-server01 sshd[9308]: Accepted password for user01 from 192.168.105.38 port 60351 ssh2

Jul  5 08:21:58 dmz-server01 sshd[9802]: Accepted password for user01 from 192.168.105.38 port 51436 ssh2

Jul  6 10:21:52 dmz-server01 sshd[21912]: Accepted password for user01 from 192.168.105.38 port 36486 ssh2

Jul  6 13:43:10 dmz-server01 sshd[31701]: Accepted password for user01 from 192.168.105.30 port 34703 ssh2

Jun 26 11:21:02 dmz-server01 sshd[31950]: Accepted password for user01 from 192.168.105.70 port 37209 ssh2

 

 

Instead of miles of gibberish the log gets reduced to passed/fail authentication attempts.

 

You can spend an hour with each log source ( firewall, AV, etc) and quickly pare them down to whats interesting.

 

Then make SURE your OSSEC  rules cover what you want to see.

If that does not work – cron a script to parse the logs of interest using your regular expression expertise and have an email sent to you when something goes awry.

 

Revisist the logs manually periodically – they will change. New stuff will happen.  Only a human can catch that.

 

Take a look at:

http://www.securitywarriorconsulting.com/logtools/

 

The site lists a number of tools that may be useful

 

John Davis added:

 

You voice one of the biggest problems we see in information security programs: monitoring! People tell us that they don’t have the proper tools and, especially, they don’t have the manpower to perform effective logging and monitoring. And what they are saying is true, but unfortunately doesn’t let them out from having to do it. If you have peoples financial data, health data (HIPAA) or credit card information (PCI) you are bound by regulation or mandate to properly monitor your environment – and that means management processes, equipment, vulnerabilities and software as well as logs and tool outputs. The basic problem here is that most organizations don’t have any dedicated information security personnel at all, or the team they have isn’t adequate for the work load. Money is tight and employees are expensive so it is very difficult for senior management to justify the expenditure – paying a third party to monitor firewall logs is cheaper. But for real security there is no substitute for actual humans in the security loop – they simply cannot be replaced by technology. Unfortunately, I feel the only answer to your problem is for government and industry to realize this truth and mandate dedicated security personnel in organizations that process protected data.

 

As always, thanks for reading and if you have a question for the experts, either leave it in the comments, email us or drop us a line on Twitter at (@lbhuston). 

Ask The Experts: Daily Tasks

Posted on by
3

This time around, we get a great question from a reader:

Q: “I’m a one man infosec team at a small financial company, and as such, I stay overtasked. Can you give me a few examples of some key tasks I should make sure I am doing daily/weekly/monthly to make sure I am hitting them all and to help me better structure my schedule?”

Bill Hagestad answered with:

Daily Tasks: 

– Keep self and staff educated about latest cyber threats to your business – read the MSI Blog @ State of Securityhttps://stateofsecurity.com/;
– Review what Federal Law Enforcement considers top cyber threats are base on current cases:
– Compromise of account holder credentials leading to legitimate account compromise;
-Via  phasing attack vectors; unauthorized ACH transfers; 
– Compromise of Third Party Payment Processors;
 
Source: FBI Threat To Financial Sector
 
-Insider attacks – perhaps the largest threat to any commercial enterprise – especially given the recent NSA dilemma via a US contractor
 
– Have staff follow all account verification standing operating procedures – covering all types of customer interaction, including but not limited to; phone, Internet, and in-person account interactions;
– Information Security/Assurance infrastructure configuration changes should be reviewed daily and approved/counter-approved internally to eliminate potential administrative abuses;
– Hold weekly Information Security/Assurance infrastructure team meetings – invite MicroSolved to participate as a credible resource for staff to ask questions of and make sound recommendations.
 
Weekly Tasks:
 
– Stay ahead of international financial sector threat intelligence – read the MSI Blog @ State of Securityhttps://stateofsecurity.com/;
– Ensure account access lists are secure and validated both for external customers (most importantly) and also internal employee need to access/right to access customer account information;
  
Monthly Tasks:
 
– Participate in professional cyber/information assurance mailing lists – if not sure who or what these are contact MSI Cyber Threat Intelligence;
– Be certain to review the US Government Hearing Notes: Cybersecurity: Threats to the Financial Sector downloadable @ http://www.gpo.gov/fdsys/pkg/CHRG-112hhrg72601/pdf/CHRG-112hhrg72601.pdf
– Review or create a cyber threat identification strategy involving key staff and MicroSolved – install HoneyPoint Security Server to capture knowledge about who truly is probing your network, eliminate the proverbial network noise and focus on specific threat actors – e.g.; Russian Cyber Crimianls, Chinese entities using government cyber espionage tools for crime purposes
 
Adam Hostetler added:
It’s hard to answer exactly what you should be doing on a timely basis
without reviewing your current requirements, tools, processes, and
infrastructure. However, If you go to www.microsolved.com and look at
our 80/20 white paper, you can use that as a guideline to give you some
ideas to help build out your security program.

Examples of some things you could/should be doing.

Daily:
Log reviews. Not necessary for all logs, but if you have
IDS/IPS/Honeypots etc, they should be reviewed and investigated if needed
Spend a bit of time following up on the latest security news/threats.
That includes things like new vulnerabilities or exploits, and then
following up if it would affect you.

Weekly:
Check and verify backups and processes

Monthly:
Update software/OS patches.

 
Finally, Jim Klun weighed in with: 
1. Make sure your subscribed to security news-feeds/alerting services that apply to your environment. Review those daily.

2. Make sure you are reviewing your logs daily.  You should know every day about successful and unsuccessful logins. You should also be paying attention to your firewall logs for inbound activity and outbound activity.

3 If you have a local help desk, talk to them at least monthly. They are often in a position to see things that are in fact security problems.

4. Automate your patching program if that is not true already, then review patch reports monthly.

5. If you have Internet exposures, check them monthly. Make absolutely sure at the end of each month you are absolutely sure of what services your organization offers to the Internet – and why.

As always, thanks for reading and if you have a question for the experts, either leave it in the comments, email us or drop us a line on Twitter at (@lbhuston). 

Ask The Security Experts: Holiday Coverage

Posted on by
3

This time around on Ask The Security Experts, we have a question about holiday coverage for the security team:

Q: “With the upcoming summer holidays and heavy vacation schedules, what are some things I need to pay attention to in order to make sure attackers don’t catch us off guard while we are short on staff?”

Jim Klun weighed in with:

1. Make sure all staff have been reminded of the reality of phishing attacks and what they need to watch out for.
   Use real-world examples like this one: http://labs.ft.com/2013/05/a-sobering-day/ ( courtesy of Adam Hostetler )
   Its important that staff understand the potential severity of a successful phishing attack.
   Such attacks are more likely over holiday periods when attackers can rely on short-staffing.

2. Make sure all systems( both network/OS/application ) are logging and that you are reviewing those logs for anomalies
   Make it a particular point to review those logs after the holidays.
   Log review can be automated but should not be reduced to a formality.  Staff with familiarity with what is normal should be reviewing daily log reports and periodically
   examining the raw logs themselves.

3. Consider internal alerting systems such as Microsolved’s “Honeypoint” solution.  They can act as tripwires in your network, alerting you to the presence of an intruder.
   See: http://www.microsolved.com/honeypoint

Bill Hagestad added:

To prevent surprise cyber attacks the number one focus should be proactive cyber threat intelligence specifically related to your company based upon the following Essential Elements of Information (EEI):

– What are your priorities for intelligence?
– Competitor’s needs/focuses?
– External vendors interests on behalf of competitor?
– Foreign economic interests
– Commercial cyber espionage
– Foreign cyber espionage?
– Potential insider threats?

Once you have prioritized what you consider the information security threats are to your organization MicroSolved can help develop a information a security/assurance strategy.
First step determine a quick list of cyber intelligence targeting baed upon the EEI above;
Second – from the priorities determine your internal High Value Targets that the prioritized list of adversaries might focus on;
Third – install or fine tune your HoneyPoint Security Server to capture attacker and threat vector information; and,
Fourth – focus holiday staffing levels and efforts to mitigate list of potential cyber threats based upon both the EEI and steps 1 -3 above.

John Davis stated:

One of the things to pay particular attention to during vacation season is the security of returning portable devices. Employees will probably be traveling all over the place on their vacations, include foreign countries. And while traveling, people like to let their hair down and take it easy. They also like to keep abreast of their emails or surf the Internet looking for restaurants and places of interest.
Hotel networks and public hot spots are usually open networks and liable to sniffing by enterprising cyber criminals. Because of this, it is relatively easy for these attackers to implant Malware on laptops or other portable devices used by traveling employees. And, as we know, lots of enterprises these days have bring your own device policies in place or tolerate the casual use of company laptops for non-business purposes. To protect the network from this scenario, run anti-virus and other Malware detecting software on these devices, and/or boot them up in a stand alone test environment and look for problems before allowing them onto the production network.

There’s a LOT of good advice here. Hopefully, some of it helps you. Until next time, thanks for reading and have a safe holiday!

Ask the Experts: Travel Abroad with Electronics

Posted on by
6

This time around, a reader wrote in with a very common question:

Q: “A member of my management team is about to go on a business trip to a country with known cyber-spying capabilities. She wants to take her phone, tablet and laptop so she can be productive on the road. What can I do to make this safer for her and our organization without restricting her work capability on the road in an unreasonable manner?”

Adam Hostetler opened with: 

The standard here is don’t bring anything electronic, if you can help it. In most cases, that’s not probable so don’t bring your normal personal phones or laptops, no smartphone at all is advisable. Bring loaner devices that have only exactly what they need and can be burned when they get back. Only connect through a VPN, and have that account monitored on the other end. Don’t leave phone or laptop in a hotel room, even in the safe, and don’t talk business there either.

Jim Klun added:

There is likely no way to do this without restricting – or at least significantly changing – the way she works. 

It has to be assumed that any information on her personal devices will be compromised. 
It also can be assumed that any information flowing between her devices and the outside world will be compromised. 

I would recommend two things:

1. Take only what you can afford to lose. Communicate only what you can afford to lose. 

        So – take a small number of devices (e.g. phone, laptop) minimally configured with only that information absolutely required for this trip. 
        Better to have corporate staff respond to email requests from her rather than to allow access to critical corporate resources from suspect location. 
        If internal connectivity to corporate resources must be allowed ( e.g VPN) it should be ideally require 2-factor auth of some sort, use strong encryption, and grant access only to a limited subset of resources. 
        All credentials can be assumed to be lost – hence the utility of two-factor.  All of the employees credentials should be changed on return. 

        All devices brought back should be assumed to be compromised and will need complete re-imaging. 
                

2.  Consider creating “go-kits” and well-defined repeatable processes for employees who travel to such locations. 

     A special set of devices ( laptop, phone, etc) that are minimally configured and can be wiped on return.  No personally owned devices should be allowed. 
     Connectivity for those devices – if absolutely needed – that allows access only to a tightly restricted and monitored subset of internal corporate resources. 
     Most importantly – training for employees who make these trips.  The employee must understand the special risks being incurred and be aware of their responsibility to protect the company and the companies existing customers.   
      As above – all of the employees credentials should be changed on return.

Bill Hagestad summed it up with this: 

This one is near and dear to my heart…I call these rules of counter cyber espionage the  李侃如的中國旅遊規則 (Lieberthal’s China Travel Rules)

Cellphone and laptop @ home brings “loaner” devices, erased before he leaves home country & wiped clean immediately upon returns;

In China, disable Bluetooth & Wi-Fi, phone never out of his sight;

In meetings, not only turn off his phone but also remove battery, microphone could be turned on remotely;

Connect to the Internet only via encrypted, password-protected channel, copies & pastes his password from a USB thumb drive;

Never type in a password directly, “the Chinese are very good at installing key-logging software on your laptop.”

The article can be found @ http://www.nytimes.com/2012/02/11/technology/electronic-security-a-worry-in-an-age-of-digital-espionage.html?pagewanted=all

Brent Huston closed with:

Any electronic items they do take on the road with them should be current on patches, AV signatures and detection capabilities. All data, drives, systems, etc. should be strongly encrypted when possible to do so (Pay special attention to export restrictions on crypto depending on where they are going.) Also, turn and burn EVERYTHING when they come back. Treat all media and data obtained during the travel as suspicious or malicious in nature. Trojans of data and documents are common (and usually they scan as clean with common tools). This is especially true for high value targets and critical infrastructure clients. Trust us! Safe travels! 

李侃如的中國旅遊規則

(Lieberthal’s China Travel Rules)


ØCellphone and laptop @ home brings “loaner” devices, erased before he leaves home country & wiped clean immediately upon returns;
ØIn China, disable Bluetooth & Wi-Fi, phone never out of his sight;
ØIn meetings, not only turn off his phone but also remove battery, microphone could be turned on remotely;
ØConnect to the Internet only via encrypted, password-protected channel, copies & pastes his password from a USB thumb drive;
ØNever types in a password directly, “the Chinese are very good at installing key-logging software on your laptop.”

Ask The Security Experts: Public Facing Workstations

Posted on by
3

This time around, we have a question from a reader named John: “I work in a small financial institution and we have problems with physical access to our computers. Many of our workstations sit in semi-public areas and could easily be attacked with USB devices or physical access when a teller or customer service person leaves the customers alone with the machine at a desk or cubicle. What advice do the experts have to help counter these types of attacks?”

Bill Hagestad started the conversation:

Recommended Points for mitigating this digital & physical vulnerability;

1) Remove workstations from semi-public areas; 2) Deploy & install single – purpose Internet workstations at no more than 2 public locations with VERY limited access to financial institution records only after 3 factor authentication has been authorized by credentialed users only; 3) Set time limites on inactive sessions on all banking terminals to logoff after physical proximity to machine exceeds 15 seconds; 4) Enforce 32 random, alpha-numeric character password changes to all critical financial institutional systems weekly; and, 5) Implement and /or continue aggressive financial institution information assurance education program with goal of 100% employee participation; review/update monthly and, 6) Mandate information security and awareness program participation from financial institution leadership throughout all employees and ranks within the organization.

John Davis expanded: I know how difficult this is for financial institutions. Your customer service representatives need computers in their cubicles in order to provide service to your customers, while at the same time those same computers are a main point of physical vulnerabilitiy. Easy steps can be taken, though, to harden these work stations.

First, workstation users should be allotted local administration rights on their systems only when a business need is present. So, CSR workstations should have their USB and DVD ports disabled. Furthermore, their is no need for them to have the ability to upload or download software. In addition, workstations in publicly accessible areas must be turned off each and every time they are unattended. Perhaps you could implement a system similar to the cut off device used on treadmills or at casinos: CSRs would have to clip a device from their clothing to the workstation before it will work. You could accompany this with biometric access for quick and easy access for the users.

Jim Klun added:

From my experience, and assuming the worst case of Windows systems configured as normal workstations with end-users having admin level access, some immediate things I would do:

1. Disable all removable media access at the hardware ( i.e. BIOS) level. At minimum: disable ability to boot from such sources. or: remove all DVD and CDROM drives and physically disable USB ports. (e.g. glue) 2. Ensure all workstations log activity and ensure that the logs are directed to a central log repository and reviewed. Example: http://www.intersectalliance.com/projects/SnareWindows/ 3. Ensure surveillance cameras cover workstation areas. 4. Aggressive screen-lock settings 5. Removal of admin access for all but limited support staff if at all possible. 6. Consider Usage of security cabinets for workstations: Example: http://www.globalindustrial.com/g/office/computer-furniture/cabinets/orbit-side-car-cabinet 7. Network Access Control to limit what devices are allowed on the local network. That unattended RJ45 jack or poorly secured wireless environment is as much a threat as that USB port or CDROM. Bluetooth setting should also be reviewed. 8. Ensure all sensitive information traveling over the local LAN is encrypted. 9. Use a firmware password ( e.g drivelock or a BIOS power-on password) to limit who can boot the machine. 10. Monthly re-iteration of security policies – including need to lock workstations. In my experience such messages are best tied to real-world examples. It makes the risk real – not just an abstract “security guy” worry. For example, this event could be used to ensure employees are aware that an unlocked workstation could lead to the installation of malware: http://news.techworld.com/security/3256513/sovereign-bank-and-penfed-warn-customers-after-keyloggers-are-found-on-laptops/

I note that both JD and Bill talk about enhanced authentication – including the use of proximity devices. Using such devices ( mostly bluetooth ) to secure these workstations sounds like a great idea to me and may be the easiest and most effective solution. Once the financial institution walks away from the workstation – it’s locked and ideally will not boot. http://btprox.sourceforge.net/ – open source Google “computer proximity lock” for a number of commercial alternatives.

Adam Hostetler closed the conversation with:

Everyone has really good suggestions so far. I am a fan of the simple phsyical solutions. I would put the workstations in locked cages. This would prevent any malicious people from inserting USB devices or CDs, or implanting sniffers between the keyboard and USB ports. Additionally, follow the other advice of disabling them through software, just to be sure.

Another solution may be to move to a thin client solution. It is possible to buy thin clients that have no USB ports or optical drives. This would also ensure that no sensitive information was on the workstation, in the event that it was stolen.