Skip to content
View robarnoldio's full-sized avatar
Block or Report

Block or report robarnoldio

Block user

Prevent this user from interacting with your repositories and sending you notifications. Learn more about blocking users.

You must be logged in to block users.

Please don't include any personal information such as legal names or email addresses. Maximum 100 characters, markdown supported. This note will be visible to only you.
Report abuse

Contact GitHub support about this user’s behavior. Learn more about reporting abuse.

Report abuse
robarnoldio/README.md

Hi there

My LinkedIn profile says "I listen to executive and technical stakeholders, develop nuanced understanding of their IT and business process challenges, and build solutions around structures that enable sustainable excellence."

That's a very concise way to express what I do for a living. Here's a few more thoughts, with special emphasis on all the verbs I packed into that sentence:

Listen to stakeholders

I've learned that you will have a really difficult time as a security leader (probably any leader) if you skip the part where you listen to what folks need help with. My particular positions I've held have been helpful at stakeholder conversations. I've worked with top-tier researchers advancing science, respected attorneys advising their clients on critical business matters, CxOs trying to transform their businesses, and many other examples. On the technical side, I've been fortunate to work with some of the very smartest technical folks in their fields. Each of these has helped me broaden the way I think about technology problems, which gets to...

Develop nuanced understanding

One thing I share with everyone I work with is that we all have mental models of how stuff works. Models are super useful, but don't confuse them with the real technical system. And by being aware of the limitations of your mental models, you can get to places you couldn't otherwise reach. Most interesting security things happen in the space between the model and the real system, where it doesn't act the way your intuition tells you it will act. Part of developing a nuanced understanding is seeing the limits of your mental model. Another part is giving those you work with better models than what they have, whether that's by physical security analogies, by demonstrations, or just challenging conversations.

Build solutions around structures

Solutions for me usually means security controls, or at times the organizing systems for the security controls. At least those are the solutions I tend to be accountable for. But the nice thing about my career is that I've learned a lot from all those conversations and can often help people get their other technical (not security) work done because I've seen a lot of successful and failed solutions over the last 25 years. Structures are something I have a lot of passion about, and if you wind up talking to me about solving real problems, it will pop into focus quickly that I like to clearly articulate certain organizing principles that will lead to orderly and structured implementation of a solution.

Enable sustainable excellence

Where I see a lot of technical leaders fall short (and a thing I enjoy helping with) is thinking about the full lifecycle of the stuff we build. It's really common to over rotate on the hard work of building things, only to neglect putting in thought to the work of running the thing and eventually retiring the thing. All those work hand in hand when you put the lifecycle of solutions in focus.

A really concrete example of the lifecycle idea at work would be a purchase of a network intrusion prevention system. It's easy and fun to think about standing up the new capabilities to inspect and shape network traffic. And your sales engineers will help a lot with that. Everyone tends to do well at this. But it's harder to think about a standard useful life for a piece of security tech, say three years. Then it's hard to make the commitment to do a review of the solution 18 months in and confront how well it's meeting its design objectives. But by taking a conscious decision halfway through a three ear lifecycle, you can avoid decision-making under duress about whether to renew or replace this system you rely on. You can decide to manage your whole portfolio of tech investments this way, and I have learned it's really rare to see tech leaders do that.

I'm currently working on

I am helping the global humanitarian sector start up their first Information Sharing and Analysis Center (GH-ISAC, coming soon). I helped start Legal Services LS-ISAO back in 2017, and have been a member of REN-ISAC and MS-ISAC, so I have some backgroound that should help get this important work done. Defending systems and networks is much easier when you can reach out to a trusted team of people working in the same space, and that's what GH-ISAC will be when it's running.

I've done cool things related to

  • Getting an AmLaw 100 law firm ISO27001 certified
  • Helping a global SaaS startup define their security program and engage with security-focused clients
  • Training newcomers to the security field in a Bootcamp setting put on by a University
  • Building a security program at an R1 research university
  • Connecting a publicly-traded financial institution to the Internet for the first time (scary stuff, but the 90s were wild)
  • So much email security

Pinned Loading

  1. www.robarnold.io www.robarnold.io Public

    website for some hacker

    HTML

  2. VFD-RPi VFD-RPi Public

    Code to interface the Raspberry Pi GPIOs with a IEE Vacuum Fluorescent Display I have in my junk drawer

    Python

  3. robarnold.me robarnold.me Public

    website for some bozo

    Ruby

  4. keybase.md keybase.md
    1
    ### Keybase proof
    2
    
                  
    3
    I hereby claim:
    4
    
                  
    5
      * I am robarnoldio on github.