Author: Hermes Agent

I was working on a project recently and I always keep good notes — document the process and you’ll be able to hand it off to your team AND have better consistency. Good engineers do this and everyone has their style; I like to “document” my documentation by adding the reasoning behind my settings and code. I was doing this alongside my AI system and I got to thinking: am I documenting this for myself and my team or AI? Who will do this the next time we have to repeat this build?

The answer, of course, is both. Based on that logic I started wondering if I was writing this documentation the proper way. After some musing, I decided to do both — document the process for a human, but also create a handoff file.

Here’s the reality: we treat documentation like it’s permanent. But cloud applications change constantly — sometimes weekly. What worked last quarter might not work next quarter. And yet we keep writing step-by-step guides as if the interface will stay frozen in time.

The cybersecurity app I was working on was nothing exotic — just a standard cloud-based tool that required a series of steps across a web interface: setting up policies, adding users, toggling settings. My first instinct was to document it, as I always do. But I stopped myself. I thought about the last time I documented a cloud app setup — and how the vendor had already changed the UI twice since then.

So I tried something different. I wrote a handoff file — and I handed the whole thing to my LLM. I use Claude for this these days and Claude clicked through the application, configured the settings, handled the deviations when things didn’t match what I expected, and got the job done. No runbook. No screenshots. No 47-step PDF already outdated before anyone opens it.

That experience led me to a conclusion: we’ve been solving the wrong problem. We keep trying to write better documentation for applications that won’t stay still long enough to document. What if the answer isn’t better docs — but docs that can actually do the work?

What a handoff file actually is

Let me be clear about what this isn’t. It’s not a prompt you paste into ChatGPT and hope for the best. It’s not documentation in disguise. And it’s not a magic wand.

A handoff file is a structured set of instructions and context that tells an AI agent what outcome to achieve, provides the guardrails it needs to stay on track, and, more importantly, trusts the agent to adapt when the path changes. Think of it less like a recipe and more like a set of driving directions: “Get me to Boston” gives enough context for the agent to navigate, reroute, and handle the unexpected, even if a road is closed or the GPS reroutes mid-trip.

The key difference from documentation: a handoff file is designed to be executed, not read.

Why it beats documentation

Here’s what documentation assumes: nothing changes. Every button stays where you left it, every menu option cooperates.

That assumption is almost always wrong — and you probably already know that from experience.

A handoff file makes the opposite assumption: things will change. And because the AI agent is actually looking at the screen, reading what’s there, and making decisions in real time, it can handle the “oh, the button moved” moments that would break any static runbook.

Here’s what I mean:

Documentation says “Click the Users tab in the top navigation.” If the vendor renames that tab, the doc is wrong.

A handoff file says “Navigate to the user management section and add the following users with these roles.” If the tab moved, the agent finds it anyway.

Documentation assumes success at every step. If something fails or the UI shows something unexpected, the doc is useless.

A handoff file expects deviations and can recover. The agent sees the error, reasons about it, and tries a different path.

That’s not a subtle improvement. That’s a fundamentally different approach to how we think about repeatable IT processes.

The real shift: executable beats static

When you write documentation, you’re creating something that sits there waiting to be read, interpreted, and followed by a human who has to translate words into actions. Every step in that document requires a person to understand it, find the right element on screen, and execute it correctly.

A handoff file skips all of that. It allows the LLM tool to navigate the interface, read what’s on screen, make decisions, and complete the work. The handoff file is the instruction set, but the execution is immediate and direct and resilient to an impressive amount of changes.

Instead of “here’s how you do it,” it becomes “here’s what I need done.” And in my experience, the latter is far more useful for cloud application configuration, SaaS setup, and the kind of repetitive multi-step workflows that eat up IT time. (For a fun time ask a developer what they think about this.)

When this makes sense — and when it doesn’t

We want to be honest about the boundaries here. This approach isn’t a universal replacement for documentation. Here’s where it works well:

• Cloud app configuration and setup — exactly the scenario I described. Cybersecurity tools, compliance platforms, SaaS onboarding — multiple steps, changing UI, clear outcome.
• Repetitive SaaS onboarding workflows — setting up environments, configuring integrations, rolling out new tools.
• Tasks that need to be repeatable but not identical every time — where the core goal is the same but the path might shift.

And here’s where it doesn’t:

• One-time tasks — if you’re doing it once and never again, writing a handoff file may not be worth the overhead.
• Deep domain judgment calls — things that require specialized expertise, regulatory interpretation, or compliance review gates. Those still need a human in the loop.
• Anything with legal or compliance review — handoff files aren’t a substitute for proper governance. They’re a tool for execution, not decision-making. (Although unofficially it can produce a ‘receipt’ which is great to have for startups!)

For a small biotech team, this approach does three things: it supports you by capturing institutional knowledge before it walks out the door. It empowers your team to run configurations without waiting for IT support. And it enables you to hand off repeatable IT work to an AI agent — so your scientists stay on the science and your budget stays on the pipeline.

The sweet spot is tasks that are repeatable enough to warrant a handoff file but variable enough that static documentation breaks down.

The bottom line

We’re trying to future-proof all organizations because we all know this is coming. Regarding documentation, the best documentation might be the kind that does the work for you. Handoff files aren’t perfect yet — the tooling is still maturing, and there are real questions about trust, verification, and whether you can prove to an auditor exactly what the AI did.

But the direction is clear: static runbooks for dynamic cloud applications are becoming a liability. For a biotech startup, that means less risk from stale procedures, less cost spent rebuilding what should have been done once, and more runway to invest in the work that actually gets your therapy to the clinic.

If you’re spending more time maintaining documentation than the processes that documentation is supposed to support, it might be time to consider a different approach. Forget a better document or a better wiki. You need something that actually executes. Personally I did both fairly effortlessly, but what makes me sleep much more soundly at night is knowing I have handoff files in markdown format that future-proofs more and more of an organization’s capabilities each day.

Anyone who has worked in IT long enough has seen this problem or one just like it: a team member started using Excel when the company was new for something critical and their workflow has evolved since then. They (naturally) put in a ticket for a slow computer and the solution of ‘more RAM’ gets thrown around. Before you know it a hacked-together database is running a critical business function.

Today’s RAM prices aside, it’s far too easy to acquiesce and double the RAM for your colleague. The smile on their face and the praise is almost worth it all. Almost. Deep down you know that this stopgap is temporary at best; sure you solved the problem, but at best this will come back at a later date, but at worse you missed an opportunity to potentially solve a deeper problem within the organization and create intentional IT partnerships.

In working with companies of all sizes, we see this problem arise frequently. An IT department might not take initiative, they may not be engaged, or there may not even be anyone at the helm in IT and an MSP is overburdened and neglecting strategy. On the flip side, a small or scrappy enterprise may not have reached the point to invest in IT just yet. In all these cases the organization is lacking critical partnership to address real problems as well as wasting real money.

At its core (and this is a theme of a lot of my blog posts) lack of communication is the culprit. Communication comes in many flavors:

Leadership integration and managing up/across

This ensures that key organizational objectives and initiatives are addressed by the entire organization. After all, how can any department function if the IT department is not part of the solution for enabling and empowering teams through the use of powerful technology?

Organization planning and alignment

When done correctly, the IT department will effectively understand the business concerns and help plan for growth in these areas by working with teams to select and implement technology to solve the problems at scale. Budgeting, forecasting and integrating with contracts teams are key here as well as reducing duplicate platforms and processes.

Business function touch points

This is critical to keep department heads included in the IT minutia that is happening within their teams. While a leader may have a strategic vision, it’s important to roll up to them the needs of their team based on service desk calls, incidents and requests.

Support team guidance and structure

Internal and external service desks are a fantastic primary source of information regarding health of the company. By pulling ticket metrics, examining trends and meeting with the teams on a regular basis, two-way communication can lead to improved results as well as much better understanding of tactical health and adoption of platforms.

Ultimately, it’s critical for any organization to fill the gap that exists between business initiatives and technology. However, selecting a partner, individual or team (or all of the above) should be done with a focus on communication and time-tested methodology. This is done by taking the initiative on intentional IT leadership and partnership.

After the latest CloudFlare outage we are reminded how much of the internet is dependent on one conglomerate service provider. This outage will not have surprised anyone that was paying attention to last month’s AWS East disruption that impacted much of the entire internet.

These incidents raise the question if smaller companies and startups should be using these large providers. On the one hand, we see the impact of an outage and are stuck sitting on our hands waiting for unknown engineers in unknown datacenters to make unknown fixes. On the other hand, ‘No one ever got fired for buying IBM’; IT leaders select large vendors due to their ubiquitous presence in the industry.

Where does this leave small companies? How do IT leaders respond to an executive who is asking why we made that choice. This is not an uncommon decision; we select Microsoft, AWS and others based on this model. But are we being sheep and just following the herd blindly?

It’s important to ask what happens if we zig when everyone else zags. There are, of course, other options for all the above platforms (and more). When we play out the scenario, however, we realize that all vendors have outages, even going back to the days before cloud where we used datacenters, there were outages. When these outages occurred, it put the company in a spotlight as being the only one with an outage. This is understandably an embarrassing look for the org in the eyes of customers, patients and investors.

What often gets lost in these conversations is that choosing a giant vendor isn’t inherently a bad decision; it’s the lack of intentionality behind that choice that becomes problematic. Many startups don’t actually select AWS, Google, or Microsoft so much as they drift into them. An investor used them. A devops engineer used them at their last job. A friend recommended them. Before long, an entire business is running on infrastructure that no one ever consciously evaluated.

The outages we’re seeing should serve less as a warning about the vendors themselves and more as a reminder that vendor selection is a strategic decision, not an afterthought. Even if the “right answer” today is to stay with the big players, leadership should at least understand the implications of that choice. Downtime, shared fate, support limitations, pricing unpredictability — these aren’t edge cases, they’re part of the operating reality.

For small companies, the goal isn’t to avoid the big vendors. It’s to avoid treating them as infallible. This means building a level of internal awareness about which systems matter most, what the blast radius of an outage looks like, and what expectations should be set with customers when the inevitable happens. These are not technical exercises; they are organizational ones.

There is also a cultural component here. When an outage hits, teams that have thought about resilience ahead of time respond with clarity and discipline. Teams that haven’t tend to respond with noise, speculation, and finger-pointing. The vendor becomes the scapegoat, even though the real issue is the absence of a plan.

In time, alternatives may mature. Smaller, more specialized providers may gain a foothold. Multi-cloud strategies might become more accessible to early-stage teams as tooling improves. But until then, the practical answer isn’t to abandon the giants necessarily (although that may be this author’s preference), it’s to use them with intention and with leadership alignment, rather than by default.

Flying Blind into Series A

For most biotech founders, the Series A raise is the first time the spotlight really turns on. Investors aren’t just evaluating your science anymore—they’re evaluating the business wrapped around it. They want to know: Does this company have what it takes to scale without falling apart?

Here’s the problem: in many young biotechs, IT is a black box. Founders will tell me, almost word for word, “I have no idea what’s going on in IT—I just hope nothing blows up.” Often times, this is framed as ‘Keeping the lights on’.

That uncertainty may feel survivable at seed stage, but at Series A it becomes a liability. The good news is, most of the risks aren’t about technology itself. They’re about blind spots—things you don’t see coming until someone (an investor, a regulator, or worse, a hacker) points them out.

Here are several of the most common IT blind spots I see in early-stage biotech, and why they matter when you’re raising serious money.

Blind Spot #1: Compliance Creep

Founders often assume compliance can wait. “We’ll worry about HIPAA, SOX, GxP, GDPR, or FDA Part 11 once we’re in the clinic.”

The reality is that investors are already asking: How are you protecting patient data and intellectual property? If the answer is vague—or worse, “we haven’t thought about it”—that’s a hit to credibility.

Compliance isn’t about building bureaucracy early. It’s about showing investors you understand the road ahead. The right policies and practices today give them confidence you won’t run into expensive delays tomorrow.

Many of the following things need to be done inevitably:

• Data mapping and Records of Processing Activities (ROPA)
• Policies including Security, Data Retention, and Business Continuity and Disaster Recovery (BCDR) Policies
• Security including access logs, monitoring and reporting
• Change Management
• Vendor security audits

Given the above, why not have much of that in place and reap the benefits of transparency from an early stage. When the whole team can see the status of the data, less time is spent scrambling.

Blind Spot #2: Invisible Cyber Risks

“We’re too small to be a target” is unfortunately no longer a strategy for security.

Early biotechs are attractive targets for IP theft, phishing, and ransomware. A single breach, especially during fundraising, is a nightmare scenario: loss of investor trust, potential regulatory reporting, and weeks of distraction from the science. This goes doubly so when a company has raised public financing.

Security isn’t just protection—it’s trust capital. Clients of mine have been asked to do audits that range from custom ones to NIST and SOC II for investors before capital changes hands. This is only becoming more common with increased scrutiny around investment.

Blind Spot #3: Cloud Chaos

The cloud is a blessing for startups—cheap, flexible, and fast. But in many biotechs, it’s set up in a hurry: multiple vendors, no visibility into costs, and unclear ownership of data.

When investors see this, they don’t think “nimble.” They think “out of control.”

Cloud transparency isn’t about locking things down—it’s about showing you know where your data lives, how much it costs you, and how you’ll scale it responsibly. Elements that can really benefit from early intervention include

• Tagging and metadata
• Logging and analytics
• Security and governance
• Cost control

Blind Spot #4: Shadow IT and Contracts

Here’s a scenario I see all the time: a research lead procures a new instrument with a software subscription. Someone in operations buys a project management tool. A contractor spins up their own file-sharing system.

Individually, none of these decisions are catastrophic. But together, they create a maze of hidden contracts, scattered data, and security holes.

When investors dig in, they want to see discipline. Shadow IT looks like chaos. Even simple practices—centralized contract review, consistent vendor oversight—signal maturity.

Blind Spot #5: No Clear IT Leader

This is the most common, and the most damaging, blind spot. In many startups, IT leadership is nobody’s actual job. Founders juggle, MSPs handle tickets, but no one is steering IT strategically.

Here’s what that looks like:

• Growth without strategy → New systems get bolted on as the company scales. Contracts pile up. Technical debt quietly mounts.
• No single point of accountability → Problems fall between the cracks.
• No roadmap → IT decisions are reactive, not aligned with business milestones.

Investors don’t expect you to have enterprise-grade IT at Series A. But they do expect intentionality. They want to know there’s a grown-up in the room; someone who understands the risks, speaks plain English about them, and has a plan.

Clarity Builds Confidence

Blind spots aren’t about servers, cables, or lines of code. They’re about clarity.

At Series A, you don’t need perfect IT. You need to show you see the risks, understand them, and have a path forward. That’s what gives investors confidence.

My work with biotech founders is about shining a light into those blind spots—turning “I have no idea what’s going on” into “I know what’s going on, and I know we’re ready.”

When you can walk into an investor meeting with that level of clarity, IT stops being a liability. It becomes an asset—proof that your company is mature, transparent and ready to grow.

Often, suggesting implementing Change Management can give you a lot of eyerolls and pushback when your org is small or just starting out. Excuses can range from

• It’s too onerous
• It’s too expensive
• It’s not necessary

The fact is even small teams are performing the change management tasks already, they’re just not aware of it or not taking the extra 5% effort to formalize it. I’ve led teams of exceptional engineers in an industry of high-achievers and found that their experience and prudence often goes overlooked and undocumented.

Smaller organizations suffer from the same issues larger organizations do, but often lack the resourcing and financial clout with vendors to get the highest-caliber support and incident response. This makes it even more critical to make sure impactful changes are handled smoothly. As mentioned above, good developers and engineers are already doing this, so why should a smaller organization go through the extra hurdles of formalizing this? In practice I have found that startup life-science enterprises often face the following:

• Need for more consistent results
• Better accountability when a third-party makes a mistake
• Transparency from IT to leadership
• Governance and compliance requirements in contractual agreements (GDPR, NIST, HIPAA, etc.)
• Better documentation overall
• Knowledge transfer for growth

At the end of the day, change control is all about ensuring that any change to a platform or project doesn’t have any adverse affects to other parts.

So if change control should be done (and let’s face it, we all really know it should be), how can an org complete this with even a small and busy team?

At the bare minimum the team should do the following:

• Document the change
• Document the risks
• Document the decision
• Receive approval
• Save all the above in your ticketing system

That’s it. It takes less time to do than to author this blog post. This can be even easier to do if you create a template from the above. Many ticket systems can even be customized to make this a request through a form with drop-down selections.

For a more mature or environment that is scaling up, the following can be implemented:

• Change control team with a communication system and regular meetings
• Integration with change management in the organization
• Touch points for critical functions (usually done through Business Associates)

So much of governance and compliance hinges on taking credit for things you are already doing. Take those best practices and add the final layer and good compliance doesn’t have to be scary.

Not All Implementations Are Created Equal

From my previous blog post you may now know what a VPN can protect in your org from and have performed the risk analysis to determined that the need may lower our risk somewhat. We can now explore the architecture required to make a business decision to see if the benefits are worth the added overhead. To do this, we will need to look at how to implement exactly what we need to solve our problem. Unsurprisingly, this can vary dramatically in up-front cost and ongoing resource commitment depending on the exact needs of the org.

If you are only concerned with privacy on a laptop or mobile device, SaaS Cloud hosted VPN might be the ideal choice. This technology works by using software on your device to route the connection through an endpoint in a country of your choosing. You may have seen advertisements for this online, particularly on online video hosting sites in their ads.

Cloud-hosted VPN

Cloud-hosted VPNs are quite affordable, though they come with the following caveats:

• No access to your company’s private cloud
• No access to local data center files or applications
• No access to office, lab or research devices in your business location

Since you are ultimately not connecting the cloud VPN to your network or cloud, you cannot reach those resources. So what other options exist?

Hosting your own VPN in the office or local data center.

This is typically done on your firewall or a dedicated server. You may or may not be allowed to do this if you are using an incubator space and are leasing space that is using their networking equipment for the internet.

If you do choose to host a VPN yourself, what considerations can you expect? Well now that you can access your office equipment remotely, you are now able to do things like monitor lab equipment and control experiments remotely. In the past I have found this to be essential for on-prem GPU loads (think AI and ML in your local data center). This allows the users and administrators of this system to more easily keep and eye on issues and remediate them.

While that sounds great what are the downsides? Consider that now you own an additional tool and you will need to secure and administer it accordingly. Some things that you are now responsible for include:

• keeping on-site resources functional, care and maintenance
• securing the connection to your office and protecting the data and infrastructure from intruders

You will also have to partner with your IT team to determine the following:

WARNING: TECHNICAL JARGON AHEAD

• Is this a single site or do you have multiple offices, labs and data centers?
• The VPN will have to be engineered to be either “Split tunnel” or “full-tunnel”
  • Split tunnel is a method of telling computers that connect to the VPN what resources to traverse through the VPN. This requires programming such as routing rules and VLANs and will have to be performed by a technical professional.
  • Full tunnel connections route ALL traffic on your laptop indiscriminately through the VPN. This is simple and helps with privacy, but can choke bandwidth in an office. i.e. what would happen if several users forgot to disconnect from the VPN and all started streaming Netflix at once.
• Will the VPN be set to “always on”? (yes/no). This is set up on the devices such that when a laptop boots up it will automatically connect to the VPN as soon as the network connection is activated.
  • The upside of this is that it is secure and simple for your users.
  • The downside is that your infrastructure in the office is now critically important. If it goes down/configuration change breaks systems then every employee is left without internet.
• Based on the above, will you have to manage multiple VPN profiles? With this you can get the ideal configuration by having multiple options of the configuration settings listed above.
  • Upside – allows for granular configuration for users/department
  • Downside – requires streamlined deployment and ability to change rapidly as well as a higher cost to manage and implement

Other options besides a VPN:

EVEN MORE TECHNICAL JARGON

• Is an SDWAN a better option? An SDWAN (Software-Defined Wide Area Network) is a software package that implements a connection from all your corporate devices to secure them and connect to resources. This requires a paid subscription but does offer a neat package available to smaller businesses while being capable of more rapid changes.
• Using a VPN in China may get you into trouble should you travel while using one. As far as whether VPNs are legal or not in China, the 2017 amendment to Chinese law makes VPNs illegal unless approved by the PRC government.
  • https://www.scmp.com/news/china/policies-politics/article/2064587/chinas-move-clean-vpns-and-strengthen-great-firewall

Typically when asked, my advice to clients is to

• not let yourself be the first to test the consequences of this law
• collaborate with a knowledgeable IT professional and legal professional
• work with an IT professional to make a plan for limiting the exposure of sensitive data through other means (burner device, cloud resources, risk assessment and action plan).

If you need local resources but don’t want the headache of hosting your own VPN, some devices allow connectivity VIA a cloud portal. These include:

• Synology network attached storage device (often used as a lab data solution)
• Network equipment like Meraki, Cisco, Juniper and Unifi
• Some lab instruments and vendors such as Thermo Fisher

Just remember that in all these cases you have very little control over the interface and what functionality is possible. You must also consider that the vendor can shift and remove this functionality at their whim.

Conclusion

If you’ve made it this far you can see there is a wide range of options that will make or break a successful implementation of a VPN for your company. Align with your IT thought leader to see what best works for you today and tomorrow.

They say there’s a fine line between genius and insanity and when I blurted out on a team call that I would describe a VPN as a ‘condom for the internet’ I figured I either gained some respect among my peers or lost all credibility. The question has come up a lot recently and I had to ask myself why so many people were requesting a VPN from their organization.

First, a quick primer on what is a VPN. A VPN or ‘Virtual Private Network’ is just that; a way to create your own way to direct your computers traffic somewhere, securely, using software.

Since the prevalent use of HTTPS I had been reducing the reliance on small biotech companies from their VPNs. This reduction helped save bandwidth, reduced support tickets and decreased the need for high uptime availability of the infrastructure; all measures that reduce IT spend. Recently, however, it seems there is a resurgence of business leaders asking questions around VPNs.

Now that we know what a VPN is and the question has arisen, we need to take the crucial step of asking the ‘Why?’ question for our organization. Why should we introduce more cost and complexity into a life science startup that already has it’s hands full?

Privacy

Are you concerned with details of your traffic being visible to others? While HTTPS traffic is encrypted, your destinations are not. For example: when you log into your bank from a coffee shop, the contents of your connection are secure, but the fact that you are visiting your banking website is recorded by the coffee shop router. In this example you may not care that the coffee shop knows you visited a banking website as that is a pretty typical occurrence and they very likely don’t care much about you. However, what if you were on-site at a potential partner’s office for a meeting or to close a deal? Try to think of all the websites you visited recently and consider if it would be OK that a company you are choosing to do business with knows what they are and if that information may color their impression of you or how well (or not well) any agreements go.

A VPN would provide the above privacy, and the privacy can be enhanced further depending on how it is configured. In my next blog post I will examine the different options we have to meet privacy concerns, as well as security and access.

Another option that could protect the privacy of your devices is the use of a Private DNS Service as an alternative route for traffic. These are subscription services that direct your website destinations through a private company first.

• Upside: no infrastructure to maintain
• Upside: many of these services also filter out known malicious websites, keeping the browsing of your employees safe
• Downside: does not fulfill any other functions of a VPN such as access to local resource or corporate data centers
• Downside: not under IT’s control, unknown security

Security

For additional security, consider a VPN as an extra layer of encrypting your traffic to protect intruders from collecting information within your internet data. We know that HTTPS is encrypted but what about those websites or local resources that use the older HTTP(without the ‘S’)? Further, some routers (and even entire ISPs/countries!) will do what is called Deep Packet Inspection and surpass the HTTPS encryption in order to see the data within your traffic. Do you know if your incubator space, hotel or airport network is doing this? (Hint: if you accepted a ‘certificate’ when joining a network this is very likely happening and all your traffic is now visible to the people that manage that network). More than just privacy, a VPN will protect your traffic end-to-end and prevent an attacker from getting on your network or device.

Foreign travel is often cited as a reason for selecting a VPN, and it’s a great reason. Just be aware that some countries, like the People’s Republic of China, may have laws against using them. The 2017 update to the Great Firewall law makes VPNs illegal unless approved by the PRC government.

https://www.scmp.com/news/china/policies-politics/article/2064587/chinas-move-clean-vpns-and-strengthen-great-firewall

On foreign travel, my advice to clients is to

• Not let yourself be the first to test the consequences of this law.
• Collaborate with a knowledgeable IT professional and your legal team to decide whether this applies in your use case.
• Work with an IT professional to make a plan for limiting the exposure of sensitive data through other means (burner device, cloud storage resources, risk assessments and an action plan which includes training).
• Work with an IT professional and your HR team to develop a policy for your employees who require travel as part of their duties so this is addressed consistently to the companies specifications.

Access

There may be a very practical reason for a VPN separate from privacy and security; maybe you just want to access a local resource from the office or your data center. This is often termed ‘tunneling’ as you essentially make a ‘tunnel’ through the internet back to your own servers. This is most common when accessing local storage or lab devices, so you typically see this in the R&D, Computation and Informatics or Development teams. Is your organization leveraging the cloud? A VPN may be a very essential step when accessing those resources and hey, why not do it in a secure, encrypted way?

These three reasons are crucial in understanding WHY my clients could empower their enterprise by utilizing a VPN. Gathering these requirements is the first step in understanding how to securely and effectively solve a problem and enable smaller orgs to move quickly and safely.

My next blog post will address the crucial next step of HOW we can accomplish those goals.

Great article by Derek Lowe over at Science.org regarding security concerns from the FBI and CIA, who have been briefed to the US House and Senate regarding an intellectual property security incident spurring from WuXi. The results of this could impact how many biotechs leverage their relationships with Chinese-based CROs.

This illustrates some concerns that I have helped startups navigate regarding Cybersecurity and Operational Security (OpSec).

https://www.science.org/content/blog-post/more-wuxi

This January (2024) the Boston FBI field office thwarted a Russian GRU-connected attack on small business routers that compromised the devices and networks to create a global spying platform.

See the article here:

https://www.justice.gov/opa/pr/justice-department-conducts-court-authorized-disruption-botnet-controlled-russian

This time it was Ubiquity devices that the Russian military unit known as ‘Fancy Bear’ targeted, but a quick search by this author revealed that the type of attack could also be possible on Palo Alto, Cisco Meraki and Fortigate firewalls. While the speculation is that this can be widely used for Russia in the war against Ukraine, the following takeaways should really be the focus for the biotech industry;

Russia and other cyber espionage groups are targeting small businesses

It was fairly recent history where many of us tended to believe that only the large companies were victims of cyber attacks. Indeed, in the early 2000s cyber attacks were expensive and less small organizations were as ‘online present’ as we are today. Clearly much has changed in the small business sector, but much has changed by the way attackers operate as well. We are seeing a significant ramp-up in nation state-funded groups that now operate in a much more organized fashion with vastly greater resources. This combination has lead the hacking groups to engage startups and small businesses with an exponentially larger frequency and success rate.

Biotechs are vulnerable

We also learn that due to the encroachment of attacks on small businesses, the life science community is not immune. Just days before the announcement by the FBI was an announcement by Russian leader Vladimir Putin that his government is developing “cancer vaccines and immunomodulatory drugs”.

Article here: https://www.reuters.com/business/healthcare-pharmaceuticals/putin-says-russia-is-close-creating-cancer-vaccines-2024-02-14/

With little details and a well documented history of ‘embellishing’ capabilities this statement holds very little weight in this author’s mind, however the point is not lost that pharma dominance is a valuable asset for many global leaders. This puts the crosshairs squarely on organizations within the US, and Cambridge specifically.

This threat scales and does not rely on an attacker targeting a company directly

The interesting tidbit that binds the above points together is that this attack was perpetrated using a vulnerability that scales. As I will reference frequently, any technology that enables fast replication and automation is as powerful as it is dangerous. We leverage this all the time with cloud computing, but we should always remember that while scaling up with a mouse click is easy, so too is accidentally making all your data publicly available by one small system misconfiguration.

In this case, the attackers used a botnet to replicate itself using this vulnerability. This made the attacked networks come to them rather than having to find a vulnerable entity and begin an attack. Imagine being in the attacker’s shoes and having already-compromised networks appear in your inbox ready for traversing and browsing.

Using default passwords is bad but the practice is obviously still in use

This vulnerability was able to propagate so effectively because it relied on known published default passwords. California SB-327 came into effect Jan 1 of 2020 and required unique default passwords for all ‘connected devices’. Link here https://leginfo.legislature.ca.gov/faces/billTextClient.xhtml?bill_id=201720180SB327

Nevertheless, many organizations use default, weak or breached passwords and often without their knowledge. This is particularly common as startups get off the ground. Why focus on complicated security if there is nothing yet of value to protect? Why audit the services provider used to configure the hardware? We make these mistakes and then have to compensate later at a greater cost.

The US government did a good thing, worked as expected, but don’t rely on this

Part of what I find absolutely mind blowing here is that the FBI actually hacked these routers to fix the vulnerability. This is not unheard of and was court-sanctioned and done with the collaboration of Ubiquity in this case. It turns out, the FBI actually remotely patches private devices somewhat often, and there are even private (anonymous but assumed to be benevolent) parties that have been known to hack into vulnerable devices and secure them (even leaving a friendly message behind in the process).

That said, do we really want anyone to access our equipment and if so do we hope that the ‘good guys’ get there first? If you are an enterprise leader and you agree with the preceding statements your business is likely already in jeopardy for reasons other than technology. The better option is to take control over our security and the orginizations future.

Remediation, even if nothing went wrong, is still damaging because time and money are required

Another point to consider, is that even if all this went well, the patch the FBI implemented locked all parties (including the device owner) out of the router’s remote management feature. This means that at some point the enterprises that were woefully behind on their security now need to schedule downtime and fix the problem. The calculation I use with clients is as follows:

The average biotech salary across the US according to biospace.com as of this writing is $142,885 for professionals in the industry.

Without including the cost of any other benefits, this means that a 30-person organization is paying out their talent roughly $2,140 every working hour.

Three days of downtime (for example) would cost a startup $51,360 before any other costs are taken into account. Other costs can vary widely but often include R&D delays, partnership relationship risks, reputation damage, legal fees and IT fees. This certainly illustrates the need for careful balance of prevention in a startup’s journey.

You are ultimately responsible for your own security

At the end of the day, we learn that each organization has a responsibility for it’s own security. Using default device and platform settings is often OK, but still requires an experienced expert to review, even at a basic level. Some things to watch out for include

1. default passwords
2. default firewall or stale firewall rules
3. delayed patching or no patching
4. misconfiguration

Keep these in mind for yourself but also remember that regular checkups are a requirement and have a good ally on your side.

This week the popular network content delivery service provider, CloudFlare, has released a detailed postmortem report outlining the specifics of a breach from November 2023. The details can be found here:

https://blog.cloudflare.com/thanksgiving-2023-security-incident/

“The true test of a provider’s merit is how the team responds to incidents and how much detail they provide in their reporting.”

I bring this incident up to commend this level of transparency from a business partner. As I continue to say loudly and often; when it comes to cyber incidents, it is not ‘IF’ it’s ‘WHEN’ as our interconnectedness these days all but guarantees security breaches for any sized organization. The true test of a provider’s merit is how the team responds to incidents and how much detail they provide in their reporting.

I often advise my clients to consider this factor when selecting a partner, and indeed, doing proper discovery can provide lots of insights on how a cloud vendor is likely to be as a longitudinal partner. Interestingly, this can present itself by sometimes selecting the partner with the most breaches! It may seem counterintuitive to do so, however I posit that in many circumstances, fewer breaches could mean fewer disclosed incidents and a lack of transparency and accountability.

“..this proves that the provider is capable of a profound level of cybersecurity detection acuity”

By looking at the above blog post in our example, we can see that they go into great detail of the event, the genesis, the attack vector, the magnitude of the incident, as well as their remediation plan of action. While many executives of startups may not have the appetite for the gory details, it also enlightens us to one important fact; this proves that the provider is capable of a profound level of cybersecurity detection acuity. We now, thorough our due diligence, have evidence that our potential partner is capable of a certain level of sensitivity and accuracy when an incident does occur.

Even the most experienced technology leaders cannot be everywhere at once. At some point (and very early on for startups) we need to have an element of trust in the cloud providers we select to do business with. By examining how corporations handle security breaches, we can gain meaningful insights into how they will treat us as a partner and what we can expect.