finos / open-source-readiness

Accelerate financial services firms’ journeys toward open source readiness, by advancing the readiness of participants’ firms and informing guidance for the broader industry in the form of white papers, presentations, and blog posts.
https://osr.finos.org
Apache License 2.0
35 stars 29 forks source link

15 March 2023 - Open Source Readiness Meeting Agenda #114

Closed psmulovics closed 1 year ago

psmulovics commented 1 year ago

Date

15 March 2023 - 1:00 PM GMT / 9:00 AM EST (be aware of the clock change!)

Untracked attendees

Meeting notices

Agenda

Decisions Made

Action Items

Zoom Details

Join by Phone

jstclair2019 commented 1 year ago

Hallo! Jim, FINOS

pholleran commented 1 year ago

👋 Phil from :octocat:

robmoffat commented 1 year ago

Rob / FINOS

caradelia commented 1 year ago

Cara Delia / Red Hat

psmulovics commented 1 year ago

Peter Smulovics / Morgan Stanley

gyehuda commented 1 year ago

Gil Yehuda (he/him) Attending (U.S. Bank)

HelloKay27 commented 1 year ago

Kay XiongPachay / Goldman Sachs

brooklynrob commented 1 year ago

Rob Underwood. Unaffiliated.

ronaldssebalamu commented 1 year ago

Hello / FINOS

robmoffat commented 1 year ago

March 15, 2023 Attendees: See:https://github.com/finos/open-source-readiness/issues/114 Scribe: Cara Squire: Peter

Meeting Notes/Action Items

OSR Articles

Placeholder owners Still need authors for some of the articles

OSR Project Plan

Personas Spreadsheet

Discussed initially at OSFF in December. Agreed we wanted personas there. https://docs.google.com/spreadsheets/d/1CwqmPo8e-oR9Iz6suPAhWS4xkZFVBNVxf9MzS6VAogU/edit#gid=854293675 Would like help completing it Rob Underwood - I don’t see legal on here. Also, PR/Executive office concerned with external communications (are you going to represent us well, messaging), finally compliance (people who say you can’t use slack/google groups - they will be concerned with what you can and can’t do. Inbound is CISO, outbound is compliance) Gil - in each section, different people take a different slice of the process. It’s important that we recognis this.
RM: Anything you need specific help with? Cara: internal stakeholders, the personas themselves. Will send out as a PDF whcih people can comment on. Over the next 2 weeks/month we need feedback. Will add to the issue.
RM: Can we fill some of this now? Rob: first few columns (CTO, CIO) it depends on why the firm is pursuing an OSS strategy. Talent is one play. Intimacy, tracking external developers, that’s another thing. Improving DevX, that’s another thing. CIO Gil: correct -- some (very few) people on this table care about open source per se. Others care about their other objectives and understand that open source may be an enabler or risk Compliance and CISO are different in banks. CISO is dealing with regulatory, (e.g. avoiding WhatsApp fine). CISO Rob: CISO will report to CTO. They’ll be the ones responsible for vulnerability. Compliance however is more of a core banking function - they may set a tech policy (e.g. can’t use Slack) they’ll be thinking about core banking compliance.
Gil: You were doing well! I like the distinctions you’re making. In banks there are often different parts for Risk and Compliance. Security has concerns. Compliance has concerns and makes sure you’re reporting about it. Very few people (on the table) care about open source. It’s either a value or a risk. They care only when it’s one of those two things. OSPO people care. The challenge is to match the activities and the concerns.
Jim: happy to have CISO and security expert as different roles. Rhyddian: since this is finance specific, might be a good idea to relate this to the three lines of defence. 1. Tech/business teams. CISO are first-line of defence, building controls, working out what needs to be done, consumption, supply chain security. 2. Independent review of that. RIsk & Compliance at this level. This is oversight of the first line. Asking: what did you say you’d do? Are you doing it? Are you managing it. 3. Is audit. They face the regulators, say that we’re doing what we say we’re doing Rob: this is smart. Banks are concerned about IP leakage. No bank wants a prop trading algo to leave. A risk person would say, hey we need a formal control. The internal audit would check this. Then, perhaps an external auditor would come check. The CISO would give thought to how the control is implemented. Who are the ones who are defining and approving audit controls, and who is responsible for implementing this in the bank? Jim: most orgs have a CRO too, running a risk program with controls that take everything into account. Cara: It’s almost like there are three levels of how to get buy in. It needs to start with the business and then sell to the other levels. We need to start on the product side. Not saying we don’t include the others but its a spectrum about how we need to engage. We need to armor the LOBs. Maybe we need to do an executive round table - have high level content and dig into stuff for LOBs. We need to speak to these departments to make sure they have what they need Madlen: Not sure if there is necessarily a chain. It seems like actually you start with people who have the passion for open source. At BMO we have lots of convinced people. YOu need to fill in all the blanks. Gil: There is a group of people who are reading the guidance and handbooks and applying it to the processes. e.g. https://www.nist.gov/cyberframework and https://ithandbook.ffiec.gov/it-booklets/architecture,-infrastructure,-and-operations.aspx There is a group of people who are reading the guidance and handbooks and applying it to the processes. e.g. https://www.nist.gov/cyberframework and https://ithandbook.ffiec.gov/it-booklets/architecture,-infrastructure,-and-operations.aspx Gil: the FDIC said this about shareware. This framework says you have to do cyber security. OSPOs say - what could we do? But in banks, it’s a case of: we’ve already told you what you have to do, make sure you’re doing that first. If you can do it with open source fair enough.
Rob: (WhatsApp). First regulation, then, clarification. All comms need to be surveilled. This is the regulator saying this. The risk and compliance folks then look at that and say, well, to comply, we need to develop controls. That may manifest itself to the CISO or maybe CTO to say, OK, we’ll do something on the firewall to make sure we follow that.
Jim: Presumably you have activities around the SDLC, how does that pertain to what the OSPO does?
Gil: I challenged whether you need an OSS policy. Really, you just need a software policy. Licences, vulns, apply to both proprietary and OSS. You should just inject the OSS specifics into the software policy. Jim: Well, if you’’re a mature org, high level of maturity..(q about internal dev) Gil: "Policy" means two things: What we claim to do (aspirationally) and what we tell the risk management people we do (and have procedures and controls about). Peter: (See below) I started writing about this. Would love involvement from others. Rhyddian: these policies are slightly different - internal software development needs a policy but as does external procurement: not limited to using internal approved tools (since you’ll use external GitHub), primarily around managing risks associated with OSS, which are different from internal software development. Gil: Policy means you have to have people around it, to prove it. An aspirational thing, we might call a policy, but actually if you put it in a policy you have to have reviews, controls etc. We shouldn’t call the aspirational use of open source a policy. Jim: I like aspirational policy, even where I agree with Gil, because (e.g. SBOMs) we trust internal devs over external ones. Because our control framework aligns better to it. Peter: I still think this is a policy. Because if I try to open source something without it, I’d be in disciplinary trouble without one.
Gil: but that policy should be covered by ethics, IP, social media, security.
Andrew: hate to add more complexity but with the new US cybersecurity policy and EU cyber resiliency act we're seeing government affairs people getting involved in open source Peter:

Roundtable

Peter discussed idea of Roundtable on 2nd May. Brittany - can we get the invite out? This would help with approvals.
Rob- computer science education fayre at the end of april in NYC. Teaching highschoolers.

Rob (M) - we may need more virtual hackathons in order to get the content into the open. Elspeth has said she has difficulty contributing her topic without the chatham house rules..

Autism Hackathon

Peter - FSI Autism Hackathon - 19/20 April