Cyberweekly #234 - Are you having a productive week?
Published on Sunday, December 17, 2023
Productivity is one of those mythical things that's almost impossible to measure for 99% of human endeavour.
We can more or less measure the productivity of people carrying our repetitive manual tasks, although much of the research into that tends to assume that those tasks really are entirely without attention, whereas in fact most factory lines are far more supervisory these days.
But our presence in the office, our ability to delegate work and our ability to get work out of the door is one measure of our productivity. But as anyone who has been told at a staff away day "We've got to go slow in order to go fast" will tell you... many of the measures and changes we can make to productivity feel more like superstition than science.
What is clear is that we are increasingly networked. Not in terms of being endlessly internet connected (although that too), but in the fact that social dynamics within teams, between teams and around the organisation probably play more of a factor in how we feel and perform at work than most people would let you know. That means that we increasingly need slack in our work day to socialise. Not just because it's fun and builds a good team, but because it's critical at building the relationships that speed up and improve our ability to do the job.
That's why as a manager, your task isn't to be the person who is best at actually doing the task (or it shouldn't be). Promotion should be reserved for those who excel at leading and managing. Those who simply perform well should be monetarily, socially and culturally rewarded, but asked to keep doing the thing they are brilliant at. As a manager, you have a totally different set of demands on your time, and so getting involved in the actual doing almost always results in you being the blocker for the work getting done.
Enabling our staff with the tools, the processes and the motivations to keep doing their job is the thing that managers can do to ensure our teams are productive. Sometimes that's giving people the slack that they need, and dare I say it, enabling them to go slow in order to go faster.
- Prepare a high-quality technical design.
- Verify that the decisions the PM makes are sensible.
- Break down the Epic into chunks, so it’ll be easier for your team to start working.
- Delegation is not about throwing off responsibility to others. It’s about sharing it.
- Never delegate 100% of a specific area. Do it yourself once in a while.
- You can share at least 50% of your current work.
- It helps the whole team when you do it.
- Developer privileges in GitHub/GitLab
- Default environment variables and configuration
- CI/CD
- Code quality checkers
- Code review settings
- Branch rules and protections
- Monitoring and observability
- Test harness
- Infrastructure-as-code
The surprising connection between after-hours work and decreased productivity | Slack
When it comes to productivity, it’s not quantity of time spent working, it’s quality
Results from the Workforce Index show that a significant portion of desk workers across the globe are struggling to balance their time at work, with different job tiers experiencing this problem in different ways.
More than one in four desk workers (27%), including more than half (55%) of executives, say they spend too much time in meetings. A similar share (25%) of all desk workers, including 43% of executives, say they spend too much time in email.
One in five (20%) don’t have enough time to connect with coworkers, and this problem is most pronounced among more junior employees.
Alarmingly, the data shows that many workers across all levels are plowing through their daily tasks without any down time: Half of desk workers surveyed (50%) say they rarely or never take breaks during the workday. These workers are 1.7x more likely to experience burnout.
Their break-taking counterparts, on the other hand, show 62% higher scores for work-life balance, 43% greater ability to manage stress and anxiety, 43% greater overall satisfaction, and—perhaps surprisingly—13% higher scores for productivity.
Interesting take from an app that seems to demand my attention all the time, although every work slack I've ever been in has a #cats channel for when you are taking those breaks!
Of course, this headline is straight from the "blindingly obvious" area of thought, but it's worth repeating to ourselves. What matters is often not the quantity of time we spend, but the quality of time.
Slack, and email to a degree, should allow for far more asynchronicity as a team, meaning you can check in on the conversation at a time when it suits you, rather than when suits others. But that culture doesn't come for free, it requires the leadership and organisational culture to recognise and value that. Otherwise, slack becomes just yet another place where your boss keeps an eye to ensure you are working late.
Why Team Leaders Give Up - by Anton Zaides
https://zaidesanton.substack.com/p/why-team-leaders-give-up
I had an assumption this was the MAIN thing I should do as a team leader:
It took tons of time from me and isolated the developers from the rest of the organization. It took me 3 years of management (and 1 in the current role) to understand I can share that work.
[...]
It’s worth revisiting once in a while what takes you time (and energy), and whether you can delegate it. Some things you definitely can’t (like 1:1s), but they are rare.
4 tips to remember:
A useful reminder that your main thing as a team lead is to delegate the doing tasks to your team, and provide them support, guidance and direction. But if you end up doing the tasks, you are doing yourself, your team and your manager a disfavour by trying to take on something that you are likely no longer enabled and have capacity to do.
The Mind of the CISO: Behind the Breach
XDR is a viable threat prevention solution. People, process, and technology improvements are sought by at least 92% of CISOs after experiencing a major cyber incident. 42% say technology not detecting a threat is a cause of the incident, so CISOs are seeking improved technology and support from their vendors. Almost all (95%) believe if XDR was in place, the major cybersecurity incident would have been prevented, demonstrating the impact efficient technology has on SecOps teams and processes.
Couple of things from this. Firstly, I thought it’s interesting that detection is the thing that CISO’s want to invest in after an incident. In my experience this is true, that in the run up to an incident, there’s lots of activity that you later think “Surely I should have seen”.
Secondly, there’s something about the fact that about a 1/3rd of CISO’s think that all of their policies and processes need a complete rehaul in the face of the SecOps movement.
(worth noting that the research was conducted by an XDR vendor, so somewhat unsurprising that they found that the thing that CISO’s need is an XDR toolkit)
Death by a thousand microservices
https://renegadeotter.com/2023/09/10/death-by-a-thousand-microservices.html
“Developer ergonomics” is the friction, the amount of effort a developer must go through in order to get something done, be it working on a new feature or resolving a bug.
With microservices, an engineer has to have a mental map of the entire system in order to know what services to bring up for any particular task, what teams to talk to, whom to talk to, and what about. The “you have to know everything before doing anything” principle. How do you keep on top of it? Spotify, a multi-billion dollar company, spent probably not negligible internal resources to build Backstage, software for cataloging its endless systems and services.
This should at least give you a clue that this game is not for everyone, and the price of the ride is high. So what about the tooooling? The Not Spotifies of the world are left with MacGyvering their own solutions, robustness and portability of which you can probably guess.
And how many teams actually streamline the process of starting a YASS - “yet another stupid service”? This includes:
And of course, multiply this list by the number of programming languages used throughout the company. Maybe you have a usable template or a runbook? Maybe a frictionless, one-click system to launch a new service from scratch? It takes months to iron out all the kinks with this kind of automation. So, you can either work on your product, or you can be working on toooooling.
This is mostly an angry developer rant, and a good one at that. I've worked on microservice systems and I disagree with some of the things in here, but something that I do agree with is that any system that allows you to start lots and lots of software projects needs to ensure you spend time and energy automating and templatising the setup and startup of those projects.
If you only have to create a brand new service and respective CI/CD system once or twice because you only have a major monolith and a couple of weird edge systems, you can probably hand crank them. But if you want to enable junior developers to start new projects easily, then you need a way to automate all of that stuff.
Developer productivity matters and microservices makes one set of tradeoffs (around reducing cognitive burden of the rest of the monolith) for another (around massively increased complexity, repetition and byzantine failure modes).
Report: Voice of the SOC 2023 | Tines
https://www.tines.com/reports/voice-of-the-soc-2023
This year’s data reveals that overall job satisfaction in the SOC remains high — security practitioners love the work they do. However, burnout is taking its toll. Leaders continue to feel their teams are understaffed and don’t have access to the tools that could automate the most mundane aspects of their work. The bottom line: more than half of respondents, across job levels, say they’re likely to switch jobs in the coming year.
This should be an alarm bell to business leaders. With both cyberattacks and skill shortages increasing, staff retention in the SOC is mission critical. The following report digs into the factors that undermine morale and offers practical solutions to help alleviate burnout and empower staff to do their best work.
3
Spending time on manual work is the most frustrating aspect of the job. If respondents had to spend less time on manual tasks, they would most likely use that time to research and evaluate new tools, develop more advanced detection rules, and integrate more systems and logs.
5
Security practitioners arelearning to code. Security teams now consider learning to code — along with computer forensics and malware analysis techniques — most important to succeed, likely because of coding’s key role in automation. No-code security solutions could provide similar benefits as organizations automate repetitive tasks.**
Ignoring the note about no-code solutions here, which I’m not fan of, this again reinforces my view that being able to code, even a little bit, is a super power that makes jobs easier and more productive. It was listed as one of the top 3 skills that SOC analysts feel they need to do their job effectively
Fighting Ursa Aka APT28: Illuminating a Covert Campaign
https://unit42.paloaltonetworks.com/russian-apt-fighting-ursa-exploits-cve-2023-233397/
Delving into more than 50 observed samples in which Fighting Ursa targeted victims with CVE-2023-23397 provides unique and informative insights into Russian military priorities during a time of international conflict for them. Zero-day exploits by their nature are valuable commodities for APTs. Threat actors only use these exploits when the rewards associated with the access and intelligence gained outweigh the risk of public discovery of the exploit.
Using a zero-day exploit against a target indicates it is of significant value. It also suggests that existing access and intelligence for that target were insufficient at the time.
In the second and third campaigns, Fighting Ursa continued to use a publicly known exploit that was already attributed to them, without changing their techniques. This suggests that the access and intelligence generated by these operations outweighed the ramifications of public outing and discovery.
For these reasons, the organizations targeted in all three campaigns were most likely a higher than normal priority for Russian intelligence.
This was an interesting point in all of this. We generally threat model against the idea that even APT’s have limited resources and when they want to use a zero-day, it’ll only be because you are a really high value target. This campaign reinforces that to a degree, but also shows the speed at which APT’s are now pivoting from “Use a zero day” to “spray and pray”. This means that the time to patch metrics are still way too high even for moderate risk organisations, because it shows that they may not throw a 0-day at you, but they may throw is very shortly after it’s exposed.
Bootstrap an Air Gapped Cluster With Kubeadm | Kubernetes
https://kubernetes.io/blog/2023/10/12/bootstrap-an-air-gapped-cluster-with-kubeadm/
Ever wonder how software gets deployed onto a system that is deliberately disconnected from the Internet and other networks? These systems are typically disconnected due to their sensitive nature. Sensitive as in utilities (power/water), banking, healthcare, weapons systems, other government use cases, etc. Sometimes it's technically a water gap, if you're running Kubernetes on an underwater vessel. Still, these environments need software to operate. This concept of deployment in a disconnected state is what it means to deploy to the other side of an air gap .
Again, despite this posture, software still needs to run in these environments. Traditionally, software artifacts are physically carried across the air gap on hard drives, USB sticks, CDs, or floppy disks (for ancient systems, it still happens). Kubernetes lends itself particularly well to running software behind an air gap for several reasons, largely due to its declarative nature.
In this blog article, I will walk through the process of bootstrapping a Kubernetes cluster in an air-gapped lab environment using Fedora Linux and kubeadm.
Airgapped environments have an air of mystery to them, but can be incredibly useful. Our systems would be significantly more secure if the control planes were airgapped, and there are plenty of architecture patterns for presenting fixed interfaces out to the world, effectively creating an airgap even on an internet connected system.
But the concepts of downloading software like this are also useful for detached development environments. Can your systems work in the case of an internet outage? Maybe you just want to get some development done while on a long plane or train journey. Not always being connected is becoming harder, and building patterns and processes that can work when the internet is unavailable is valuable capability building.
0xB455/m365-fatigue
https://github.com/0xB455/m365-fatigue/
This Python script automates the authentication process for Microsoft 365 by using the device code flow and Selenium for automated login. It keeps bombing the user with MFA requests and stores the access_token once the MFA was approved.
It is intended to be used in Social Engineering / Red-Team / Pentesting scenarios when targeting O365/MS-Online users in Azure (now called Entra ID).
In case a username & password combination was compromised it can be used to flood the authenticator app with authentication requests. Once the second factor has been approved the valid JWT access_token will be stored in decoded and encoded format locally. The token can be reused in other tools like TokenTactics , GraphRunner or manual requesting different endpoints in Azure... ****
This shows just how easy it is to fatigue a user with MFA prompts
Southern District of New York | Two Russian Nationals Charged For Conspiring To Hack The Taxi Dispatch System At JFK Airport | United States Department of Justice
From at least September 2019 through September 2021, DEREBENETC and SHIPULIN, who are Russian nationals residing in Russia, and ABAYEV and LEYMAN, who are U.S. citizens residing in Queens, New York, engaged in a scheme (the “Hacking Scheme”) to hack the Dispatch System at JFK.
At all relevant times, taxi drivers who sought to pick up a fare at JFK were required to wait in a holding lot at JFK before being dispatched to a specific terminal by the Dispatch System. Taxi drivers were frequently required to wait several hours in the lot before being dispatched to a terminal and were dispatched in approximately the order in which they arrived at the holding lot.
Beginning in 2019, DEREBENETC, SHIPULIN, ABAYEV, and LEYMAN explored and attempted various mechanisms to access the Dispatch System, including bribing someone to insert a flash drive containing malware into computers connected to the Dispatch System, obtaining unauthorized access to the Dispatch System via a Wi-Fi connection, and stealing computer tablets connected to the Dispatch System. The members of the Hacking Scheme also sent messages to each other in which they explicitly discussed their intention to hack the Dispatch System. For example, on or about November 10, 2019, ABAYEV messaged the following to DEREBENETC in Russian: “I know that the Pentagon is being hacked[.]. So, can’t we hack the taxi industry[?]”
At various times between November 2019 and November 2020, DEREBENETC, SHIPULIN, ABAYEV, and LEYMAN successfully hacked the Dispatch System. They used their unauthorized access to alter the Dispatch System and move specific taxis to the front of the line, thereby allowing drivers of those taxis to skip other taxi drivers waiting in the line. ABAYEV and LEYMAN charged taxi drivers $10 each time they were advanced to the front of the line and transferred part of their profits to SHIPULIN and DEREBENETC.
Just a nice reminder that huge amounts of cyber attacks are just a couple of people out to make a couple of bucks. As always with fraud, the underlying action isn’t the complex bit, it’s getting the money from your victims and into your bank accounts that gets you caught.
USING AI TO SEARCH FOR CASE LAW AND MAKE SUBMISSIONS: IT MAKES CASES UP – IT REALLY DOES – Civil Litigation Brief
**“Having considered all the points set out above, we find as a fact that the cases in the Response are not genuine FTT judgments but have been generated by an AI system such as ChatGPT.”
THE CASE** The appellant appealed to the First Tier Tax Tribunal in relation to a penalty arising from capital gains tax. The procedure involved her filing a Response. That Response set out a number of previous decisions that appeared to assist the appellant. However there was no citation and, upon close examination, it was clear that the cases did not in fact exist. The Tribunal concluded that this was because the Response had been generated by an AI system.
This is going to increasingly waste time in law courts around the world, and I’m not really sure that there’s anything anyone can do about it.