Compromised API Key, Invalid Capacity Offer, and Settlement Exposure
Solaris Aggregation operates a 200 MW wind farm and submits day-ahead offers through a third-party API. At 11:40, an attacker uses a stale API key, disabled at 11:55, to submit a 300 MW supply offer at €0/MWh for the 18:00–19:00 delivery hour. The offer clears; the market operator expects 300 MW, but actual metered output is 180 MW. The imbalance price for that hour is €200/MWh. The market operator's data team notices the offer exceeds the farm's registered capacity by 100 MW and that the API key was used from an unrecognised IP address. The settlement statement is due at 10:00 the next day. Solaris's SCADA logs are intact, but the bid log shows the malicious entry with a valid digital signature. The incident response team must decide whether to request a settlement correction, notify the regulator, and how to prove data integrity.
1. Quantify the settlement exposure and explain who bears the imbalance cost.
Read the worked answer
The cleared offer was 300 MW at €0/MWh, but actual output was 180 MW. The shortfall is 300 - 180 = 120 MW. At the €200/MWh imbalance price, the exposure is 120×200 = €24,000 for the hour. The market participant is normally responsible for deviations from its final position, so Solaris bears the imbalance charge unless the market rules allow a correction for an unauthorised bid.
The offer also exceeded registered capacity by 100 MW, so the market operator's validation failed. That is a data-integrity issue independent of the cyber attack. Solaris can request a settlement correction, but it must prove the bid was not authorised, that it acted promptly, and that the correction is permitted by the rules. The €0 offer may also have displaced other generation, creating a market-wide cost beyond Solaris's own charge. The settlement statement should show the €24,000 exposure; the correction request should be filed before the deadline with supporting evidence.
2. Outline the incident response and evidence-preservation steps.
Read the worked answer
Contain the incident: revoke the stale API key and all related credentials, rotate secrets, block the unrecognised IP, isolate the API gateway, and require manual approval for new bids. Preserve evidence with a forensic image of the API gateway, bid log, SCADA, authentication logs, and network logs. Hash the evidence and maintain chain of custody; do not overwrite logs. Determine scope by searching for other bids from the same key or IP, other compromised accounts, and any access to settlement data.
Notify the market operator immediately, not at the settlement deadline, and request a bid correction or a hold on settlement while the facts are established. Activate the incident response plan and involve legal and regulatory reporting. Contact the third-party API provider. A valid digital signature proves the key was used, not that the bid was authorised, so Solaris must show the key was compromised and that controls failed. The response should also check whether other market participants were affected.
3. Recommend data-integrity controls and regulatory notifications to prevent recurrence.
Read the worked answer
Controls should include multi-factor authentication, IP allowlisting, per-key bid limits, validation against registered capacity, anomaly detection for price and volume outliers, four-eyes approval for large or late bids, immutable audit logs, scheduled key rotation, and vendor security assurance. Reconcile submitted bids against SCADA and actual capacity before gate closure. Separate duties so the person who submits a bid cannot also approve a capacity override.
Notify the market monitor and the relevant regulator under the incident-reporting rule. Provide a timeline, affected hours, settlement impact, containment steps, and remediation. Consider whether personal data was breached. After the incident, complete a root-cause analysis, test the recovery, update the incident playbook, and verify any settlement correction. Data integrity requires that the bid log be trustworthy: signed entries, synchronized time, restricted access, and an audit trail that distinguishes key use from human authorisation.