I'm a BISO and so can you (Part 2) - Running the Business Information Security Office

Welcome to the long overdue second half of the BISO two part article series, where we talk about the day to day aspects of the BISO team. If you are not familiar with the term “BISO”; it stands for Business Information Security Office (or Officer), and you really should go read about the background and the value this role brings to your organization in Part 1 (Found here!) before going any further. For Part2, we discuss such aspects as management of a BISO team, team goals, the basic “toolset” a BISO should use, project tracking and executive reporting. Ready? Let's get into it! 

Like any other member of the Cyber team, the BISO will need a clearly defined role, obtainable goals and means to achieve those goals. Unlike many other roles in the security space, the BISO role doesn't have an extensive history in the industry, or clearly defined performance metrics like one might see on teams such as Vulnerability Management, Identity Access or Red Team. There are no clear BISO owned problems; nor can you track/report a well defined BISO solution such as a patch, or a script deployment. In many ways, a BISO acts as a middle-man of information and planning, and is meant to function as a social lubricant to achieve alignment of goals between business and cyber groups. That's why we said in part one that a BISO acts as a communication conduit between product teams and cybersecurity groups. Let’s say your Governance, Risk and Compliance (GRC) team works with the BISO to help facilitate a new internal assessment. The BISO might work with the product team to help collect information, or to better explain the goal of specific control, recommendations, or even advise during the remediation effort to become compliant. But once the assessment is complete, it is the GRC team that reports on the results, and the product team that gets the thumbs up on their remediation effort. What did the BISO team actually do? We will come back to this question. 

                                                                     *   *   *

Let's get into what a BISO needs to have available to them to be successful. These are resources, processes (both internal and external) and a basic toolset. No doubt there is more, but if you have the items below, you should have a solid foundation for a working BISO team.  To start, let's align your team to your company! Take a look at part 1 to understand how to align the BISO team to the company business model. You should be able to say this line about any company process… “This is Process X on Product Y, that product's/team’s BISO is Joe”. For that to happen, the BISO team member’s first goal should include discovery and relationship building:

1. First is the goal of discovery and awareness. Meet and talk to as many team leaders as possible, learn what they do, and what products they make. Cultivate a relationship with those leaders and learn their strengths and pain points. This includes teams on the Cyber side and your Customer (or product) side. 

2. Develop connections in the PMO team, GRC team, Enterprise Architecture and Threat Management team in charge of application/red team/vulnerability scanners. These teams provide information your product teams and leadership are going to need. Meet with these teams on a monthly basis. 

3. There must be a clear delineation of who owns what process or system. The BISO team must have connections in the system ownership groups that keep the gold images, and spin up new hosts. If there is a finding on host X, what product does it fall under, and who owns that?

4. Once these relationships are established and BISO team members are aligned, chart who is aligned to what, and make that information public. As the BISO lead, you will manage upward as needed and give this mapping to your CISO, who will in turn continue to echo your message. 

Next let's address your basic BISO toolkit. It will contain a number of quick but valuable resources to share with teams at any time, as needed. Here you can expect to find a boiled down version of information from cyber teams and product teams about their ongoing efforts as well as BISO employee facing pages. These include:

1. A BISO Website - Get in touch with the SharePoint team that runs the company homepage, and build a team page to show what BISO does for which part of the company. Give a face to the name. 

2. Build an Intake process for new requests, a feedback survey for completed ones, and a team distribution list for people to CC the BISO group on email chains. 

3. Create a Scrum/Kanban board to track team assignments. This will be especially handy as problems, or solutions that one BISO finds might be used by the rest of the team. 

4. Build a “What is a BISO slideshow” - which would explain what a BISO does, with process flows and examples of challenges and solutions. These roadshows will bring clarity to what the team does, but also entourage people to reach out with requests. 

5. Connect to the Risk portfolio and share it ( this is created from numbers provided by the GRC team, red team, vulnerability management team, enterprise architecture, PMO, infrastructure) - the BISO should be able to illustrate at a glance where there are gaps in every department as they relate to each of these teams. 

6. Work on a detailed enterprise mind map. Is every team covered? What do we do for the teams that are not. 

Now we are at part three, let's get this pipe moving some information. It is time to define a baseline of what service your BISOs provide. They must be well rounded, at 

1. Start by creating a gap analysis of routine meetings. Which BISO is meeting with whom and how often. That table of meetings should be consistent for all BISOs and well rounded.

2. A weekly check-in meeting with your team members to make sure no one on the team is dealing with an issue everyone should know about. This role functions as a unit, not as a group of individuals.

3. Create a dashboard of your scrum board, showing how many stories are being worked on at any time for any product “pillar” or single BISO. Make sure the load is the same. 

4. Ensure that a monthly check-in happens where a BISO Risk Portfolio is being shared, and acted on by the pillars. They should know what problem spots they have, and how to dig deeper to get to the root cause. 

5. The notes from your monthly meetings with Cyber teams should be created into a newsletter for the product teams. 

6. The notes from your product teams should be created into a newsletter for CISO.

                                                                     *   *   *

For our last topic let's go back to that question. Once the assessment is complete, it is the GRC team that reports on the results, and the product team that gets the thumbs up on their remediation effort. What did the BISO team actually do?

1. The BISO was the one who made sure that the finding was communicated to the correct team with context and focus (awareness)

2. They ensure that the product team is able to address the finding without impacting the business. (Impact analysis)

3. The BISO made sure that remediation SLAs were not broken. Or if they were, it was done with understanding and ample warning. 

4. They also were there to explain the finding, work on a plan to build a solution, and discuss effective and available mitigating controls, if a solution isn't viable. 

5. Once the effort of remediation was on its way, the BISO will communicate it back to the correct cyber team, making sure they understand the timelines and resource constraints 

6. When the remediation is complete, they communicate it to the rest of the BISO team to ensure a consistent message with other pillars with similar findings in the future

In short, they will get none of the immediate project credit, but they will use their connections, process and toolkit to ensure a successful cyber process today and in the future. 

Want to talk more about BISO topics or need some advice? Let me know! I’d love to learn from you or help with your projects.