Closed psmulovics closed 1 year ago
Hallo! Jim, FINOS
👋 Phil from :octocat:
Rob / FINOS
Cara Delia / Red Hat
Peter Smulovics / Morgan Stanley
Gil Yehuda (he/him) Attending (U.S. Bank)
Kay XiongPachay / Goldman Sachs
Rob Underwood. Unaffiliated.
Hello / FINOS
March 15, 2023 Attendees: See:https://github.com/finos/open-source-readiness/issues/114 Scribe: Cara Squire: Peter
Placeholder owners Still need authors for some of the articles
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:
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..
Peter - FSI Autism Hackathon - 19/20 April
Date
15 March 2023 - 1:00 PM GMT / 9:00 AM EST (be aware of the clock change!)
Untracked attendees
Meeting notices
FINOS Project leads are responsible for observing the FINOS guidelines for running project meetings. Project maintainers can find additional resources in the FINOS Maintainers Cheatsheet.
All participants in FINOS project meetings are subject to the LF Antitrust Policy, the FINOS Community Code of Conduct and all other FINOS policies.
FINOS meetings involve participation by industry competitors, and it is the intention of FINOS and the Linux Foundation to conduct all of its activities in accordance with applicable antitrust and competition laws. It is therefore extremely important that attendees adhere to meeting agendas, and be aware of, and not participate in, any activities that are prohibited under applicable US state, federal or foreign antitrust and competition laws. Please contact legal@finos.org with any questions.
FINOS project meetings may be recorded for use solely by the FINOS team for administration purposes. In very limited instances, and with explicit approval, recordings may be made more widely available.
Agenda
Decisions Made
Action Items
Zoom Details
Join by Phone