Forem: Dominique Rene

Data Privacy in Regulated Applications: What Developers Need to Know

Dominique Rene — Mon, 20 Apr 2026 10:46:44 +0000

Regulated apps are different from regular software in one uncomfortable way: you're legally required to collect data you'd rather not touch. Government IDs. Social security numbers. Real-time location. The regulatory mandate forces you to gather sensitive material — then separate laws demand you protect it. That tension doesn't get resolved in a compliance meeting. It gets resolved in your architecture, or it doesn't get resolved at all.

The KYC Pipeline Problem

Most teams make the same mistake with KYC: they treat it as a feature rather than an isolated subsystem. The result is government ID scans sitting in the same database as user preferences, accessible to the same application services, shipped to the same logging aggregator.

The first structural question worth asking early: should you store raw identity documents at all? In many cases, delegating to a KYC provider — Persona, Jumio, Onfido — and storing only the verification reference and outcome is the cleaner path. Your database holds kyc_status: verified, provider_ref: "abc123", and a timestamp. Nothing else.

However — and this matters — some gaming regulators explicitly require independent retention of identity documents, not just a third-party reference. Michigan's MGCB technical standards, for example, have specific data retention obligations that may require you to hold copies directly. Check the jurisdiction requirements before assuming delegation is sufficient. Your compliance and legal team needs to sign off on the storage model, not just your architect.

When you genuinely need to retain KYC data (some jurisdictions require it), keep it isolated:

users → user_id, email, created_at

kyc_profiles → kyc_id, user_id, status, verified_at, provider_ref

kyc_vault → encrypted blob, strict ACL, separate credentials

The vault should be unreachable from your application layer by default. Only a dedicated compliance service touches it, and every read gets logged. Not application logs — a separate audit trail.

Field-level encryption matters here more than disk encryption. Encrypting at rest protects you if someone walks out with a hard drive. Field-level encryption protects you from your own engineers, your own queries, and your own misconfigured storage buckets. Use your KMS to encrypt SSN, DOB, and document hashes individually. Decryption should require explicit, logged justification. For a concrete implementation pattern using KMS-backed field encryption in a serverless context, this production walkthrough is worth reading — the key policy scoping discussion alone saves most teams a painful mistake.

Verification drift is consistently underestimated. A user's KYC is valid today. Eighteen months later, their document has expired or your provider's risk model has shifted. Build re-verification flows before you need them. Stale KYC is both a compliance liability and unnecessary data exposure — you're holding sensitive material past its useful life with no corresponding obligation.

Geofencing Without Storing Location

Jurisdiction enforcement creates a specific constraint: you can't just verify where a user lives. Confirming where they physically are at the moment of a transaction is a fundamentally different problem.

The instinct is to log GPS coordinates with timestamps. Avoid it. That's a detailed record of someone's movement patterns, and regulations typically require proof of the check result — not retention of the raw coordinates themselves. Minimize what you collect to what the obligation actually demands.

A cleaner pattern:

Client → sends coordinates to internal GeoValidation service

GeoValidation → checks against jurisdiction polygon

→ returns: { permitted: true, jurisdiction: "MI", checked\_at: timestamp }

Main app → stores result only, coordinates discarded

Short TTL caching on geo results is reasonable — re-checking on every request creates more location data than required and adds latency. But keep the TTL short on financial transactions. Minutes, not hours. Users can cross state lines.

On mobile, request whenInUse authorization, not always. Background location collection is rarely justified by the actual regulatory requirement. If your legal team pushes for it, ask them to point to the specific obligation. Usually they can't.

IP-based geolocation is a useful secondary fraud signal — but under GDPR, IP addresses (including hashed ones) can still constitute personal data if re-identification remains possible. Treat IPs as PII by default, minimize retention, and don't treat IP geolocation as primary jurisdiction evidence. It's a corroborating signal, not proof.

Logging Is Where Privacy Goes to Die

Application logs are the most overlooked PII risk in most systems. Engineers treat them as ephemeral debugging tools. In practice, they're shipped to third-party aggregators, retained for months, searchable by broad engineering teams, and occasionally exported during incident investigations.

A log line containing a user's email, IP, and a behavioral event is personal data under GDPR, regardless of your intent when writing it. The solution isn't better scrubbing — it's not writing it in the first place. If you want a solid grounding on exactly what GDPR classifies as personal data and how the storage limitation principle translates into engineering constraints, this dev.to breakdown covers it without the legal padding.

Pseudonymize at write time, not after. Your log pipeline should never receive a raw email address. It receives an internal pseudonymous ID instead. The OWASP Privacy Cheat Sheet lays out data classification and pseudonymization requirements clearly — worth keeping open when defining your log field taxonomy. Classify every log field explicitly:

✅ user\_id: "usr\_8f3k2" — pseudonymous internal ID

✅ action: "kyc\_check\_passed" — behavioral event, no direct PII

❌ email: "user@email.com" — never in logs

❌ ip\_address: raw — treat as PII, minimize or drop

❌ ssn\_last4 + user\_id — linkable combination, avoid

Note on IP addresses specifically: hashing doesn't automatically resolve the GDPR question. If the original IP can be reconstructed or re-identified through other means, a hashed value may still be personal data. The safer default is not retaining them in logs at all unless there's a documented, necessary purpose.

Audit logs operate under entirely different rules. Compliance requires an immutable record of access and actions — append-only, write-once, accessible only to your compliance function. Engineers debugging a production incident should not share an access tier with your financial audit trail. These are separate systems with separate purposes, and treating them as one creates both security and compliance exposure.

Scrubbing middleware on outbound log streams catches mistakes. It's not a design strategy — it's a fallback for when the actual design fails somewhere.

Retention Is an Engineering Problem, Not a Policy Document

Every regulated company has a retention policy. Far fewer have the technical enforcement of it. The policy says "delete KYC documents per regulatory schedule." The data sits in production indefinitely because no one built the deletion job. The NIST Privacy Framework treats data lifecycle management — including retention and disposal — as a core engineering outcome, not an afterthought. It's a useful structural reference when you're defining what "done" actually looks like for a retention program.

Retention windows vary significantly by jurisdiction, data type, and applicable regulation — the figures below are illustrative starting points, not legal requirements. Validate specifics with counsel for your target jurisdictions:

Data Type	Retention Window	Enforcement Mechanism
KYC raw vault	Account lifetime + jurisdiction requirement	Compliance workflow, manual review gate
Geofence results	90 days	TTL field, rolling purge job
Session/auth logs	90–180 days	Log store TTL config
Financial records	5–7 years	Legal hold check before purge
Behavioral/marketing data	12 months	Scheduled deletion, user-scoped

The right-to-erasure problem in distributed systems is harder than it first appears. Deleting a user means accounting for: primary database, read replicas, analytics warehouse, event streams, backups, third-party KYC provider, email service, and any other downstream system you pushed their data into. Build a data subject request (DSR) workflow that fans out across all stores. Retrofitting this is significantly more painful than building it early.

For records you're legally required to keep, anonymize the user linkage rather than deleting the record. The transaction happened, the financial record stays — but the user_id foreign key gets replaced with a non-reversible hash. Compliant retention, no live PII.

Soft deletes (deleted_at column) are not privacy-compliant deletion. They're a UX convenience that leaves data fully intact. For regulated data, you need either hard deletion or cryptographic erasure — delete the encryption key, and the data becomes permanently unreadable without requiring a physical delete.

What Regulated Betting Applications Actually Look Like

Online sports betting is one of the most instructive domains for this kind of engineering. The compliance surface is unusually wide: state gaming authority requirements, AML obligations, age and identity verification mandates, and consumer privacy law all apply simultaneously — and they don't always point in the same direction.

Applications supporting sports betting in Michigan operate under Michigan Gaming Control Board oversight, which imposes specific technical requirements around identity verification, geolocation, and record retention. CCPA adds a further layer for any California residents using the platform — note that CCPA scoping depends on user residency and operator thresholds, not just the state of operation. These obligations coexist with platform-level privacy commitments and create a genuinely complex compliance matrix.

In practice, this means a KYC gate at account creation that hard-blocks product access until verification is confirmed and stored per the applicable retention requirement. Geo-check middleware injected at the transaction layer — not just login, but every wager. An audit pipeline physically isolated from the observability stack, with access controls that don't overlap with general engineering. A compliance data store with credentials that most engineers never hold.

The betting domain is worth studying even if you're building healthcare software or fintech tooling. Regulatory pressure is intense enough that architectural shortcuts are genuinely costly — teams in this space have had to solve these problems for real, under audit, rather than deferring them to a future sprint.

Practical Checklist

KYC storage model has been validated against jurisdiction-specific regulatory requirements — not just assumed
Identity data lives in an isolated schema with field-level encryption and separate credentials
No PII written to application logs — pseudonymization at the source, not post-hoc scrubbing
IP addresses treated as PII by default — not retained in logs without documented necessity
Geolocation data is ephemeral — check result stored, raw coordinates discarded
Audit logs are append-only, on a separate pipeline, inaccessible to general engineering access
Retention windows are technically enforced — TTLs and scheduled purge jobs, not just documented policy
A tested DSR workflow exists that fans out deletion across every data store, including third parties
Third-party KYC and data vendors have signed DPAs
Soft deletes are not used as a substitute for compliant deletion of regulated personal data
Erasure approach (hard delete vs. cryptographic erasure vs. anonymization) has been reviewed against applicable DPA guidance
Geo-check middleware runs at the transaction layer, not only at authentication

7 Practical Lessons for Solo Game Developers

Dominique Rene — Wed, 11 Mar 2026 12:48:54 +0000

Solo game development looks efficient from the outside. One person, one vision, fast decisions. In reality, it is usually slower, messier, and more demanding than expected. The same person has to design systems, build mechanics, create or source art, test the game, manage scope, and keep the project moving when motivation drops.

Many projects stall not because the idea is weak, but because the process is unstable.

The most useful advice for solo developers is about structure, restraint, and making fewer expensive mistakes. The points below focus on that side of development: how to reduce rework, keep momentum, and make better decisions.

1. Write things down before production starts

A solo project does not need a heavy game design document. It does need a clear record of what the game is, what it is not, and what must exist for the first playable version to work.

A short design brief is enough at the start. It should define:

The core loop
The target platform
The main mechanics
The fail state
The progression system
The visual direction
The minimum feature set for MVP

Once features, rules, and assumptions are written down, it becomes easier to spot contradictions early.

For a simple ball runner, even a one-page brief can reveal important design questions immediately. Will the player control movement by swipe, tilt, or joystick? What counts as failure? How is progression unlocked? What is the purpose of collectibles? Is the game score-driven, level-driven, or both?

Documentation also matters later, especially once systems start interacting. A developer who adds a new skill, an enemy, or a UI flow three months into production should not have to reverse-engineer their own project. If one mechanic touches five scripts, that relationship should be recorded somewhere. Otherwise, every change turns into a memory test.

2. Study references with intent, not imitation

Reference gathering is often treated too casually. A folder of screenshots is not research. Useful reference work breaks successful games into decisions.

Why does a certain movement system feel responsive? Why does one reward loop keep players engaged while another feels flat? Why does a visual style look coherent even with low production complexity? Strong reward loops can extend the value of player progress beyond gameplay. In some cases, this even leads to secondary markets where advanced profiles are traded, such as listings for Fortnite accounts for sale.

Looking only at games in the same genre is also limiting. Strong solutions often come from adjacent spaces. A mobile puzzle game may offer a cleaner onboarding structure than a platformer. A strategy game may have a better progression cadence than an action title.

That kind of analysis helps in two ways. First, it sharpens judgment. Second, it gives the developer a realistic vocabulary for solving problems without having to reinvent everything from scratch.

3. Scope the project around real constraints, not ambition

This is one of the most common causes of stalled indie projects. The concept is built around what would be exciting to ship, not around what can actually be finished with the available time, skill set, and budget.

A solo developer has to be blunt here. If the project requires custom character animation, complex AI behaviors, online systems, handcrafted levels, live balancing, and original art across dozens of environments, the real question is whether that workload matches the available resources.

A better approach is to scope from constraints upward.

If the art pipeline is weak, use a style that is simpler to produce consistently.
If programming is the bottleneck, build around mechanics that can be implemented and maintained without fragile system sprawl.
If the budget is zero, search asset stores and free libraries before planning bespoke production.
If time is limited, design for a short path to MVP.

Many solo projects get stronger when their limits are accepted early. A smaller game with coherent execution beats a larger one that lives in permanent rework.

A useful reality check is this: a prototype that takes a weekend to build can still take three or four months to turn into a real product. MVP is not the finish line. It is the point where the actual production work becomes visible.

4. Cut weak ideas early

Not every feature deserves persistence. Some deserve removal.

A mechanic that never feels right, a leaderboard with no clear purpose, a visual style that keeps forcing rework, a progression system that adds complexity without making the game more interesting, these are not always challenges to push through. Sometimes they are signals.

Solo developers lose a lot of time by trying to rescue ideas that are wrong for the project. The sunk cost makes it harder to admit. Weeks disappear into redoing assets, rewriting systems, or polishing features that were never central to the experience.

A better rule is simple: if a feature causes disproportionate friction and still does not improve the game, cut it or reshape it.

This also applies to technology choices. If the toolset is slowing development, if the chosen implementation path is becoming harder to maintain, or if a core decision keeps breaking adjacent systems, the project should pause long enough to reassess.

There is also a deeper discipline here: fail fast and fail cheap. If a project keeps slipping, feels increasingly heavy, and no longer responds well to iteration, it may be better to stop, extract the lessons, and start the next project with a cleaner plan. That is not wasted work. It is often how real progress begins.

What matters is pattern awareness. One abandoned project can be useful. Repeating the same abandonment cycle across multiple engines, multiple concepts, or multiple restarts points to a process problem that needs attention.

5. Build the core systems before investing in content

A lot of unnecessary work happens because production assets arrive too early. It is tempting to start rendering characters, polishing UI, animating enemies, or buying content packs before the game structure is stable. That feels productive. Often it is not. If mechanics, camera behavior, level scale, lighting, combat rhythm, or readability are still in motion, then most content decisions are provisional.

That means rework. A safer sequence is:

Lock down the core loop
Validate controls and camera
Test level scale and pacing
Establish visual readability
Expand content production

Even a few finished examples are enough during early development. One enemy, one environment slice, one UI flow, one polished interaction. That provides a quality target without forcing the entire project into premature asset production.

This is especially important for developers who use mixed pipelines, such as 3D renders converted into 2D sprites, or stylized assets that require custom processing. In those cases, late changes to lighting, scene scale, or presentation can invalidate much of the finished work.

6. Show the game early, but choose the audience carefully

External feedback matters. Working alone for too long creates blind spots. A mechanic that feels obvious to its creator may confuse everyone else. A visual direction may make sense internally, but it reads poorly to players. A reward loop may look complete but fail to motivate.

Still, early feedback works best when the audience matches the stage of the project.

During rough development, developers and genre-aware testers are often the most useful because they can identify structural issues without being distracted by unfinished presentation. Later, once the game has enough shape to be legible, broader audiences become more valuable. Friends, family, and non-developers can reveal whether the game communicates clearly to ordinary players.

That sequence matters. Showing a barely formed prototype to the wrong audience can produce noise instead of insight. Generic reactions like “it looks strange” or “I do not get it” are not always helpful when the system is still skeletal. On the other hand, waiting too long to get feedback can lock weak decisions into the project.

A practical approach is to ask different people different questions:

Fellow developers can evaluate system clarity and implementation choices
Genre players can react to balance, pacing, and feel
Nonspecialist players can reveal usability problems and onboarding friction

7. Protect sustainability, or the project will slow down on its own

Burnout does not always look dramatic. Often, it appears as slower decision-making, weaker judgment, more feature-hopping, and a longer recovery after small setbacks. For solo developers, this is dangerous because there is no spare capacity in the team to absorb the drop.

Working every available evening and every weekend may feel like a commitment. Usually, it is a short-term productivity gain followed by a longer productivity collapse.

Consistency beats intensity.

A healthier and more effective approach is to set realistic weekly goals, keep the project moving regularly, and maintain actual recovery time. This might mean working on the game for a limited period each weekday and keeping weekends mostly free, or it could involve a different schedule that suits the developer’s lifestyle. The specific structure matters less than the principle: momentum should be sustainable.

Several habits help:

Plan work one week at a time
Define the next small set of shippable tasks
Separate deep work tasks from admin tasks
Avoid using all rest time as production time

A note on using existing tools, assets, and code

Solo development does not reward purity. It rewards completion. There is no extra credit for building custom systems that already exist in stable, affordable, or free form. Off-the-shelf tools, asset packs, sample implementations, and middleware can significantly reduce production time when used effectively.

That said, reuse should be selective. Imported assets and premade systems should serve the project, not define it by accident. The goal is not to collect components. The goal is to assemble a game with a consistent identity.

A note on using AI

Used carelessly, generative tools can create more problems than they solve. Code produced without understanding often ignores the structure already present in the project, introduces unnecessary complexity, and makes maintenance harder.

Used carefully, these tools can still be useful. They are better suited to explanation than authorship. They can help clarify syntax, compare implementation options, or break down unfamiliar patterns. They are much less reliable as silent replacements for engineering judgment.

Marketing starts earlier than most developers think

Even strong games struggle when visibility becomes an afterthought. For solo developers, that usually means:

Identifying the audience early
Understanding how the game will be described in one sentence
Collecting material that can later support a store page, demo, or trailer
Knowing when public visibility helps and when it distracts

Not every project needs to be shown publicly from the first prototype. But every project benefits from thinking about discoverability before the final stretch.

Final thought

Solo development becomes easier once the project stops being seen as just creative energy and instead is viewed as a series of production choices. Most unfinished games don't fail because the creator lacked passion. They fail because the process couldn't support the ambition.

Leveraging Automation and Expertise in SIEM Systems

Dominique Rene — Thu, 23 May 2024 08:20:02 +0000

The shortage of information security specialists cannot be resolved quickly through mass job advertisements or higher wages. Infosec systems require extensive knowledge and highly qualified experts, often needing long-term training.

For example, when implementing and using SIEM systems, experts need to connect and cover the necessary sources of information security events with normalization and enrichment rules, create and configure threat detection rules, constantly monitor the quality of data supplied for analysis, respond to identified incidents and investigate them.

These tasks require extensive training in cybersecurity as well as a deep understanding of information systems and their data flows. Additionally, specialists often struggle to determine the necessary steps for responding to and investigating incidents. Addressing all these challenges can be difficult not only for beginners but also for experienced experts.

Focus on automation

In a personnel shortage, managing a SIEM system should be straightforward for operators, analysts, and users with minimal experience with the product.

To minimize the time between the start of illegitimate activity in the infrastructure and its detection by the SIEM, as well as the time from incident detection to confirmation and response, the system should handle most expert functions. This includes helping define monitoring objects, preparing normalization rules, tuning correlation rules, minimizing false positives, checking verdicts, and automating the entire event processing pipeline.

Top requirements when choosing a modern SIEM

A SIEM system should continuously analyze the protected perimeter, identify IT systems and their information flows, and provide recommendations for their control and protection. It should specify which data sources need to be monitored. An effective SIEM can automatically connect new event sources as they appear on the company’s network and prioritize their control based on their type.
A quick start and detection of information security incidents should be possible in any infrastructure, whether it involves familiar information systems or systems unknown to the vendor. The initial connection of new sources should not require the operator to know specialized languages for writing normalization rules.
One common problem in almost any organization is shadow IT - devices, computers, servers, services, or software used by employees that do not comply with security policies. A modern SIEM should continuously monitor these shadow segments by automating the collection of data from the network.
The threat landscape for various organizations and sectors is constantly evolving, with attackers continually developing new techniques and tactics. Therefore, the system should rely on the broadest possible expert base, including the vendor, the community, and the company's own information security specialists. It should also have a wide range of tools for consolidating this knowledge.
Additional validation of registered incidents should be conducted using third-party systems, such as external TI systems or third-party correlation engines. Providing a second opinion should become a mandatory practice.
The SIEM should offer recommendations for responding to identified incidents, as well as for investigating and processing them. These recommendations can be based on internal expertise or response rules generated by the community and integrated into the system.
A smart SIEM continuously adapts to changes in the information security landscape and enhances the accuracy of incident detection. For example, integrating telemetry data from workstations with XDR systems can improve the detection of dangerous security events. Therefore, having simple integration interfaces with third-party systems is essential for future SIEM systems.

In conclusion, automating SIEM systems is essential to address the shortage of information security specialists. By simplifying operations and enhancing efficiency, SIEM automation ensures effective threat detection and incident response, even with limited personnel expertise.

Trends and Future Prospects of SIEM Systems

Dominique Rene — Wed, 22 May 2024 14:13:04 +0000

Security Information and Event Management (SIEM) combines real-time monitoring, analysis, and response to security events with the collection and storage of security data. It helps organizations detect, respond to, and prevent cyber threats efficiently. As technology advances, SIEM evolves to meet new challenges. Here are several trends shaping the future of SIEM.

Clouds

Many organizations are now shifting their IT infrastructure to cloud services. The way systems interact and transmit information in the cloud is different from traditional local infrastructure. With this move towards cloud-based solutions, SIEM systems are also transitioning to the cloud. However, for some clients, it is still important to maintain some on-premises components. For vendors, it is essential to expand the visibility scope to include both network devices and cloud environments.

New Formats

In cloud infrastructures, the rethinking of SIEM system architecture has led to new formats of operation, such as SIEM-As-a-Service. Previously, the primary format for SIEM outsourcing was through MSSP providers. However, recently, there has been a growing number of providers offering SIEM as pre-configured software combined with cloud computing resources.

New Features

In addition to changes in the platforms for implementing SIEM systems, the required capabilities have evolved as well. For example, SOAR systems used to be separate products that were sold independently. Now, many manufacturers have started including orchestration components within SIEM systems. Some vendors have acquired existing SOAR systems and integrated them into their SIEM offerings, while others have developed their own orchestration components from scratch.

Automation and orchestration features are now available in many SIEM systems, but they come with their challenges. These features can significantly enhance SIEM usage, but only if the organization has a sufficient level of maturity. SOAR requires prior training in systematizing and formalizing processes. As the functionality of SIEM systems expands, the demands on the SOC team also increase.

XDR Integration Trend

Today, SIEM has evolved beyond just a correlation tool to become the central hub of a SOC that is responsible for monitoring and responding to cyber incidents. As a result, there is a trend towards closer integration with third-party solutions, with such interactions being more natively incorporated into the product's architecture from the outset.

SIEM systems are evolving from advanced log management tools into complex solutions for responding to and also removing Trojans and other types of cyber threats. The XDR concept embodies this shift by integrating multiple types of solutions into a single platform, ideally managed through a unified interface.

This system expansion demands highly qualified specialists to work with SIEM. On one hand, SOC management becomes easier because the number of different interfaces is reduced and their logic is unified. On the other hand, it becomes more challenging because a highly skilled specialist is needed who is well-versed in all the components of this integrated system.

The product needs to be simplified as much as possible in terms of user interaction, while customer companies still have high expectations for pre-installed content. Finding a balance between simplicity and comprehensive features is another emerging trend.

Machine Learning

Machine learning remains relevant and has advanced significantly over the past few years. However, its applicability depends on the specific and narrow focus of the field. SIEM systems perform specialized tasks, and machine learning technologies are only suitable for some of these tasks. Currently, some SIEM system vendors include a UBA module, which typically helps analysts identify important events from user activities and assets within large data streams.

This sphere is transitioning from using correlation rules to creating datasets for training models to analyze events and potential attacks. Analysts will primarily focus on developing these datasets and verifying alerts from such intelligent systems.

Currently, these modules are primarily in demand by large organizations with a high level of IT and information security maturity. This is because machine learning requires significant investments while addressing a relatively narrow business task - assisting information security specialists in automating the decision-making process.

Many organizations prioritize perimeter protection before focusing on detecting anomalies in user behavior. As a result, not all companies are integrating machine learning technologies into their SIEM systems yet. This is not a widespread practice but rather a trend for the future.

SIEM's Future Landscape

The trends described above have been developing for some time and remain relevant, but they are not permanent. It is expected that some of them will decline soon. There is even speculation that within the next two to three years, SIEM may disappear as a distinct category. Vendors might create ecosystems where some functions are absorbed by data analytics platforms for security events while comprehensive solutions like XDR take others over. However, these are bold predictions, and their likelihood is uncertain.

What is certain is that SIEM systems will continue to evolve, offering more advanced analytical capabilities to detect complex and hidden threats, such as anomaly-based attacks, insider threats, and the use of distributed traversal techniques.

Best software developers will continue to improve the user experience by providing a more intuitive interface and enhanced data visualization. This will help security analysts better understand information and speed up the process of detecting and responding to incidents. High-quality expertise is also expected to be available out of the box, making it accessible to a wide range of specialists.

Additionally, it will be important to supplement SIEM systems with data on external risks using threat assessment services tailored to specific organizations. This will enable SIEM systems to consider the information that attackers may already have.