Cyberweekly #201 - Just do it

Published on Sunday, July 03, 2022

You don’t need a Platform, you need One Thing That Works — Federal Field Notes

https://federal-field-notes.ca/articles/2021-06-21-you-dont-need-a-platform-you-need-one-thing-that-works/

A platform is a foundational, reusable technological building block — colloquially, “ anything you can build upon .” Think of a platform as a base “Lego” mat that you put your other pieces on top of.

A good platform solves a problem really well for many different products . An example of this is your Google Account, which signs you into Gmail, Google Calendar, and Youtube (and other apps that use “ Sign in with Google ”). There are lots of things you need to ‘Sign in’ to do, and it would be silly to have all teams everywhere build their own account management system. Better to solve it in one place in a way that everyone can use (otherwise you may end up with almost 60 separate login systems ).

[...]

But let’s not get ahead of ourselves. While platforms have the potential to enable scalable product delivery, they can just as easily become — perhaps one of the most fun words in the English language — a boondoggle. The Canadian government is littered with plans for premature ‘platforms’ that suck time and energy from more useful deliverables for years at a time.

[…]

A handful of teams each building something that works is going to get you lots of useful insights (what data is shared, what data is unique, where is the greatest load in the system, etc). But instead, departments often create siloed “platform teams” trying to design a perfect solution without a real-world deliverable. And meanwhile other teams waiting around are told either to (a) wait until the platform is ready (it’s already been delayed twice), or, if you can’t wait, then (b) build another product with the 20-year-old technology we are trying to move away from. Here again, ‘enterprise thinking’ is a backwards approach, leading to ‘platforms’ that block teams instead of enabling them.

[…]

This is what the essence of agile development is all about.

Pick a well-scoped problem, build it with boring, well-documented technology , and solve a problem for real users .

Instead of diving head-first into a big abstract platform, it’s much easier to reason about a concrete use-case: building out a small end-to-end slice of a larger service and using that as a building block. You can then expand that service by making your app more complex and able to handle more traffic, or by decomposing it into separate services if you want. Aim to evolve your services as you go and create platforms where they are most needed, not because you have a diagram that says so.

I wanted here to quote the entire article. This is brilliantly written, and while Canadian government specific, the lessons here are applicable in all the enterprises that I’ve worked in before.

We should have a predilection for action, for building the thing. Find a problem, solve the problem, rinse and repeat. We instead want to admire the problem, to look at just how impressive a problem it is, and then design the perfect platform or framework that can solve the problem.

Exercising Influence as the Security Team: Look for Friction Not Just Fuel — Discernible Inc

https://discernibleinc.com/blog/exercising-influence-as-the-security-team-look-for-friction-not-just-fuel

According to Nordgren, this is because we naturally understand behavior in terms of internal forces such as motivation and intent. These are “fuel.” When people don’t take the action we want, we often (incorrectly) assume the appeal is insufficient, so we try to increase the appeal with more fuel.

For security teams, it can seem easier to look for a bigger, flashier solution instead of smaller solutions that could help address friction. Yet, Nordgren cites the common but incorrect assumption that adding more gun powder to a gun will make a bullet travel faster or farther as an analogy for how a focus on fuel can be counterproductive. Although gunpowder is responsible for the initial velocity of a bullet, the reason a bullet is able to fly so far and so true is because of its aerodynamic design. The shape of the bullet helps reduce the friction, or drag, caused by wind resistance and gravity. Adding more gun powder actually creates more drag.

How many appsec or product security engineers spend hours every day trying to convince developers and other engineers to patch their systems or fix code vulnerabilities? Depending on the size of your organization, your team could potentially have dozens of identical and duplicative negotiations happening at any given time with cross-functional team members. Each of them are fighting to add more gunpowder instead of making the process more aerodynamic.

In this kind of situation, I often find significant friction from the lack of formal incentives for developers to maintain the health and quality of their code. If security considerations aren’t mentioned in leveling ladders or performance reviews, the headwinds preventing developers from prioritizing security work is very strong. This is where CISOs and senior members of the security team need to flex their influence and relationships with their senior engineering peers to negotiate for security to be an official expectation of their team. For all the CISO’s reading, if you don’t already have this kind of influence, it’s not too late to start earning it. You can remove a lot of headwind for your entire team.

This is a great read, and I love the analogy of fuel versus friction.

Of course we need both in organisations. When I give conference talks, I always make sure to give some context about why we care about security, sometimes with scary headlines, but mostly just setting the context that there’s a real set of security concerns that we have to worry about. Sure, for some of us, this is just “known”. But everytime I give those talks, I find a decent proportion of people in the audience, especially those who are young or new developers, had simply never heard that before.

But as the article says, simply scaring people and adding to their cognitive load without doing anything to help them isn’t sufficient. Those education and awareness developments really quickly peak out their return on investment and stop being valuable. But actually reducing the friction for people in your organisation requires a huge amount of investment in areas outside of the purview of the typical CISO, which is much harder than funding yet another phishing awareness campaign.

The Reporting Line of Security Teams / CISOs - Updated

https://www.philvenables.com/post/the-reporting-line-of-security-teams---cisos-updated

The reality is, like every important concern, security has to be a shared goal - one role can’t carry this alone no matter where it reports.

In my view the issue that confuses matters in all the debates about reporting lines stem from the intermixing of two distinct roles for getting security right.

There is the role of embedding security into all products (technology, business process, services and so on). This is now a profoundly engineering-centric role in most organizations, being that most organizations are now or are becoming predominantly digitized. This role/team needs to be where products are built/maintained so the embedding is efficient (secure products not just security products), and that knowledge is current and security engineers are intimately tied to product mission. In short, this role is in IT / engineering.

There is the role of enterprise risk management. This role/team makes sure that the risk appetite of the organization, as set by executive leadership and the Board, is independently enforced and any variances are handled at a level above where a trade-off is occurring. In many organizations this is the role of a Chief Risk Officer (CRO) or similar and there will exist a team to independently assess and manage the risk appetite of a range of specific risk domains, including security. In short, this role is in the enterprise risk function.

This is really well articulated. I think that organisations can have one person and indeed one role handling both concepts, but it really needs to be clear that they are wearing two hats and they need team members that have the relevant skills in the right areas. It’s important that you don’t have risk managers opining on how teams should make technical decisions, or security analysts opinion on enterprise risk unless they are appropriately trained and capable.

The saddest "Just Ship It" story ever

https://kitze.io/posts/saddest-just-ship-it-story-ever

For 2 frickin' years, I thought it's too early to release my app because it's clunky, buggy, it's missing features, blah, blah, blah. No one would ever use it, right? I was so wrong.

I started using their app.

Even though they were working on it for the past few years it's still slow, buggy, and super unpolished, it doesn't matter, because they shipped.

Their mobile app is terrible and it needs 10 seconds to sync. It doesn't matter, they shipped. And I'm looking forward to every single update they release.

Their backlog of things to do is huge, but it doesn't matter, they ship every single week, and the app is growing along with the community.

"But Kitze, even though tHeY sHiPpEd no one would pay for something unpolished and broken, right?"

Oh, Indie Hackers. So clever, yet so naive.

Today my 30-day trial has expired. A tear rolled down my cheek for every single digit of my credit card that I entered in their app. I am officially not only a subscriber, but also a fan. Every time I'll get a payment notification it's gonna feel like stepping on a lego ... glued to a knife. My bank might as well change the notification from "You have paid 5$ to ThatCompany" to "You never shipped, loser".

My app is officially dead.

99% of you are in the same boat right now, but hopefully just a few weeks into your project. Don't be a dumbass like me. Take a breath, roll your eyes at the cliche saying, but please...

Just Ship It.

P.S I would totally release and show you my app but ... it's not ready yet.

Really nicely put story as to why it’s important to get stuff out there in front of users. One quote, which I can’t find a reference to now, said of the Minimal-Viable-Product methodology “You get to decide what minimal is, and the market gets to decide what viable is”. This is a good reminder that if you’ve not shipped it, then it’s not possible to even see if it’s viable. With no customers at all, you’ll never get the feedback to know whether you’ve done enough to make it viable.

Just ship it, and put it in front of people, that’s the only way you’ll ever know

Anna Shipman : JFDI

https://www.annashipman.co.uk/jfdi/good-bad-tech-strategy.html

I covered what strategy is and what makes a good strategy (both very much distillations of the excellent Good Strategy, Bad Strategy ), and then I talked about what a good tech strategy looks like.

This is a great summary of a book I really enjoyed and found useful. Anna brilliantly summarises and brings to life the 3 main steps of building a good tech strategy.

1. Diagnosis of the problem
2. Vision for the future
3. A plan on how to get there

Critically she really manages to pull together just how a tech strategy must align with a business strategy, and useful and important the plan part is

Trunk and Branches Model for Scaling Infrastructure Organizations | Irrational Exuberance

https://lethain.com/trunk-and-branches/

The solution I’ve found effective for addressing the infrastructure organization rules is an approach I call the Trunk and Branches Model . You start with a “trunk team” that is effectively your original infrastructure team. The trunk is responsible for absolutely everything that other teams expect from infrastructure, and might be called something like “Infra Eng,” “Platform Eng,” or “Core Infra.”

As the team grows, you identify a particularly valuable narrow subset of the work. Valuable here means one of three things:

1. it’s an exponential problem that will overrun your entire organization if you don’t solve it soon; for example, test or build instability accelerating as you hire more engineers
2. It’s a recurring fire that is undermining your company with users; for example, database instability causing site outages
3. It’s an internal workflow that’s starving your team’s ability to make investments; for example, a clunky process for manually spinning up new services in a company accelerating service adoption

You then create a narrowly focused “branch team” that wholly takes responsibility for that subset of work. This might be a Storage team that is responsible for all real-time data storage and retrieval. This might be a Services team that is responsible for all service provisioning. This team is responsible for both solving the immediate and long-term problems associated with their area of focus. Providing operational support within their vertical ensures they are tightly connected to their users real problems. Sufficient team staffing to support investment allows them to solve problems through platforms and automation rather than linearly scaling the team’s staffing.

This is a nice description of a good management model and applies for almost all “enabling functions”.

To do this, you’ve got to be able to measure where your work and effort is spent, measure what the demand for your time is, and have permission to grow the team constantly to deal with the problem.

One thing that isn’t covered in here is how to graft branches back into the trunk. In some cases, a “branch team” might grow out and stay its own team forever, but in some other cases, they might be able to focus on automating the problem until its small enough to merge back into the continuous work that the trunk team does.

In a growing stage 2 or stage 3 startup, this isn’t likely a problem, but outside of silicon valley style tech startups, infinite team growth can’t be guaranteed, and so you need to ensure that teams understand that they are on a mission, and that mission is to spend a year or 18 months making the problem solvable and automatable so that the main team can now handle it.

The Plight of Cinderella Services | by Cate McLaurin | Medium

https://cate-mclaurin.medium.com/the-plight-of-cinderella-services-1701299d8d6d

It’s about a lack of dynamic capabilities from the legacy of new public management which leaves us unable to adapt and innovate, and a lack of trust in organisations which leads to process heavy solutions and risk averse thinking within enabling functions. Too often the process, and how well that process is working in terms of outputs not outcomes, becomes the thing.

And there’s a real need for us to do things differently if we are to really create an entrpreneurial state so that we can tackle our big societal problems.

‘forget the moon shot and the north star, the way that we operate within the department and our investment in the enabling functions is woeful. So we’re never going to be able to deliver all these things unless we can pay attention to what’s actually going on under the bonnet of the car.’ (quote from a senior central gov digital leader)

Absolutely fabulous writing from Cate McLaurin and identified something that really resonated with me.

Too many digital transformation initiatives focus on the user facing experience as if that's the only thing that matters. The lack of change of the core business enablers means that even if successful, you often end up with an "alien artifact", a team, service and set of processes that sits awkwardly in the organisation, unable to develop true value or even change appropriately as the organisation changes.

#1622449 June 2022 Incident Report

https://hackerone.com/reports/1622449

On June 22nd, 2022, a customer asked us to investigate a suspicious vulnerability disclosure made outside of the HackerOne platform. The submitter of this off-platform disclosure reportedly used intimidating language in communication with our customer. Additionally, the submitter’s disclosure was similar to an existing disclosure previously submitted through HackerOne. Bug collisions and duplicates, where multiple security researchers independently discover a single vulnerability, commonly occur in bug bounty platforms. However, this customer expressed skepticism that this was a genuine collision and provided detailed reasoning. The HackerOne security team took these claims seriously and immediately began an investigation. Upon investigation by the HackerOne Security team, we discovered a then-employee had improperly accessed security reports for personal gain. The person anonymously disclosed this vulnerability information outside the HackerOne platform with the goal of claiming additional bounties. This is a clear violation of our values, our culture, our policies, and our employment contracts. In under 24 hours, we worked quickly to contain the incident by identifying the then-employee and cutting off access to data. We have since terminated the employee, and further bolstered our defenses to avoid similar situations in the future. Subject to our review with counsel, we will also decide whether criminal referral of this matter is appropriate. Our full discussion of the incident is below.

This is a nasty insider threat incident, and massive props to HackerOne for being quick to identify and handle the incident, and being public about the issue.

When independent security researchers submit their data to hackerone, they trust that it’s going to be passed to the affected company, and this can be worth a lot of potential money in terms of bug reports. As an insider, being able to then see these and reach out directly is… both bad, but also astonishingly stupid.

Of all the things that this actor could have done, deciding to reach out with threats to the target company was just begging to be caught. If instead they had sold the information on dark markets, sold it to law enforcement or intelligence organisations, or used it to carry out their own cyber operations, then the impact would have been far harder to identify, and would ahve probably earned them more money over time.

Sometimes when it comes to bad actors, we get lucky, and they’re not actually the worst case scenario that we worry about.

Sharing our Engineering Career Framework with the world - Dropbox

https://dropbox.tech/infrastructure/sharing-our-engineering-career-framework-with-the-world

At Dropbox, we strive to be a great place for all engineers to grow and be recognized for that growth. Our Engineering Career Framework helps keep us accountable there and is viewable by anyone within the company. Today, we are also making it viewable by anyone outside the company. Our goal in doing so is to be transparent externally on how we think about leveling and career progression on the Engineering team at Dropbox. It also enables others to adapt and apply it to their own organizations.

In early 2020, we completed a major revision to the framework. Our focus was to be more explicit about the “what” (i.e. business impact made) and create better representation for all the different crafts within engineering that make Dropbox successful. After a year of running this current version through several promotion cycles, we are satisfied that it is moving our culture in the right direction.

Dropbox’s Engineering Career Framework describes what’s expected for our engineers at each of our career levels. Along with helping managers set expectations and hold teams accountable for their work, this resource empowers engineers to achieve greater impact in their role and grow in their careers.

This is quite old, it’s been sitting in my queue to share for over a year now, but I really like the transparency that has been increasingly coming from tech organisations about their career frameworks.

Tools like this help us understand whats common between companies, and set our levels right. They also help us to understand people who are coming in from another company, to work out what level they were expected to work at.

FBI: Stolen PII and deepfakes used to apply for remote tech jobs

https://www.bleepingcomputer.com/news/security/fbi-stolen-pii-and-deepfakes-used-to-apply-for-remote-tech-jobs/

The Federal Bureau of Investigation (FBI) warns of increasing complaints that cybercriminals are using Americans' stolen Personally Identifiable Information (PII) and deepfakes to apply for remote work positions.

Deepfakes (digital content like images, video, or audio) are sometimes generated using artificial intelligence (AI) or machine learning (ML) technologies and are difficult to distinguish from authentic materials.

Such synthetic content has been previously used to spread fake news and create revenge porn, but the lack of ethical limitations regarding their use has always been a source of controversy and concern.

The public service announcement, published on the FBI's Internet Crime Complaint Center (IC3) today, adds that the deepfakes used to apply for positions in online interviews include convincingly altered videos or images.

The targeted remote jobs include positions in the tech field that would allow the malicious actors to gain access to company and customer confidential information after being hired.

This is a predictable development, one with probably a fraudulant but not necessarily as scary a motive as might be made out. The implication in here is that these are really bad actors trying to get into your system, which it might be, it’s a neat way of getting into a system. But it’s also a length attack process, you’ve got to find the right job being advertised, apply, run the deep fake scam and then get in.

It’s far more likely that this is something that’s cropped up before, but taken off during the pandemic due to remote working, which is paying for someone else to take the interviews and tests for you to get into a good job. Contractors and consultancies have done a form of this bait-and-switch for decades. The number of times I’ve interviewed a top tier consultancy, met some experts in their field, and then the team who actually turns up is mostly brand new graduates and cheap subcontracted labour that cannot deliver on the promises made.

But now, with deep fakes and increasing remote only work, someone can change who is behind hte screen, meaning that they can get through the difficult parts of the interview and then hand the work off to someone else.

Of course, this still presents a huge security problem for companies in the sense that you really need to know who your employees are, and what accesses you are giving them, and confidence in things like background checks and financial health checks.

But expect more of these stories to emerge over the next year as people get more remote work savvy, and critically, these kinds of frauds are incredibly difficult to keep up over time.