 So, hello everyone, we're very excited to be here today at the 2017 OASP Convention. This is our third time actually. Recently we've spoken at the AppSec in Europe, and this time we want to talk to you about a very important matter. The Game of Thrones. But not just any thrones, the product throne and the security throne. Now how many of you are Game of Thrones fans? Woo! Okay, how many of you don't know what I'm talking about? Okay, it's half and half. So you should look at the series, you can catch up with us later. It's one of the most popular series and one of the best actually in my opinion. And even if you haven't heard of it, maybe you've heard that recently a certain politician said the Game of Thrones can be used as a handbook for politicians. So we think it's not just for them. Specifically the first scene during the meeting between Jon Snow and Daenerys, shown in the last season, season 7. Now I'm sorry for the spoiler, but just google it, trust me. That scene is how this lecture was born. DLPM, I was recently came to you to warn you about danger approaches. The army of hackers coming, they're going to steal all our customers' data. What? That's just a fairytale. We've had a strong firewall for years and there's never been a breach. Listen to me, I was there, I was behind the firewall. I saw them, the hackers are here. And you have three strong development teams. Why do you not put them on the task to close all vulnerabilities we have? Then we can spend the chance. Yes, I understand you, but there's a bigger issue here. I received the last garden report. And our competitors have our place, the upper right quadrant. That belongs to us. If anything, I'm sending my teams out on that task. After that, maybe I can help you defend our customers. Unfortunately, it might be too late. It might be less than a place to defend. So you get it right, Jon Snow. Hi, Derek. Thank you. But what do you think? Does this conversation happen between the business and the security? Never. I was just going to ask you how often do you think it happens if you think it happens, but you're right, it never happens. It doesn't happen. Actually, in reality, this wall is not in the land far, far away, but it is right here. Now, luckily enough, Elena is a security officer. Elena, you can come closer to me. Luckily enough, Elena is a security officer, and I'm a product manager, and we do speak a lot, actually. So we've come to share with you our knowledge and tools about how you can break this wall in your organization. But first, we need to find common goals, a common language. And what is the mother tongue of all product managers? Can you guess? Money. Of course, money. Seriously, what real goals which product manager and security person can share? Really, we have actually a big list, but in big picture, we can say that we both want to build our customer trust while we create the solid reputation for our company, and definitely we want to get some profit during this process. But needless to say, this can only be gained with joint effort. Those of you who saw our former presentation know that we are strong believers in joint effort and team spirit, and this can only be gained if you not just start talking but also act as one team. So who are we and why we are standing on the stage today? Obviously, to illustrate you that product manager and security lead can talk when they have shared goals. And our goal today is to share with you our experience and knowledge and to illustrate how you can get our knowledge and apply in your organizations too. So Elena represents the security side of the project. She brings vast experience in both software development and security areas. She went through various roles such as software developer, technical lead, system architect, and for the last four years as application security lead. And the front represents the product side of the team responsible on roadmap feature prioritization budget. And also she has a very deep knowledge and experience in both software development and product and project management. That's me. So first, before we dive into the practical aspects, I would like to give you some deep insight about the product management role. Who is the product manager and what does he do all day? So as we heard before, the mother tongue of all product managers is money. But is that really reality or is that just a stigma? So let's look at the stigma versus reality table. So first of all, we have the busiest person in the company who sees only dollars versus innovation and technology. He is the anti-start, anti-security, anti-technology, anti-technical depth, anti-automation, and anti-everything that is efficient. On the reality side, we still have the busiest person in the company, but did you ever ask yourselves why? This is because the product manager engages in various stuff, such as product definition, roadmap definition, feature definition, meets with customers, participates in sales meetings, strategy mapping, competitive analysis, and of course defines the product lifecycle, which we will talk about in a minute. And dollars versus technology? Of course, but that is only because there is a budget after the pricing model, the licensing model, that is the sole responsibility of the product manager. And the anti-start? Well, the product manager has to take hard decisions of prioritization, and maybe this is why everyone views him as the anti-start. So as you can see, the product manager has to juggle so many balls in the air that every ball that you put in increases the chance of everything falling. So do we blame him for overworking security? Yes, we do. Obviously. You just should not do this alone. If two people juggling together, we can have more balls in the air and have much bigger ball effect. So how we suggest to solve it? We suggest to align product management processes with security processes. Did you say processes? That's my point. I just love processes. So now I want to explain something to you, the product lifecycle. This is a product lifecycle that every product undergoes. It's called the PLM, the product lifecycle management. It is an enterprise-wide discipline that provides guidelines and management for a full lifecycle, for a full product lifecycle, from design and concept through manufacturing and production to service and sales. The PLM integrates between systems, people and processes. It's very similar to the project management lifecycle, but from the content point of view. And it is not just only for software technology, it is also a business strategy. Let's go over the stages in short. We have the inception. This is where we conceive the product, where we just lay down our wish lists and thoughts, our roadmap with no limits of efforts and capacity. Wouldn't that be great? There's the definition stage where we define the features functionality. There's the planning stage where we do the planning together with the development teams and prioritize. There's the design stage where we define more features, prioritize more, get into more details. I'll talk about that later. We approve POCs and approve demos of done features. This is where the manufacturing gets done, the development and the QA. Then we have the release. The product manager approves the sign-off and we have the release of production. And then we have service and post-production, where the dev gives support, and the product engages in up-sales and stuff like that. Now, when we wanted to combine the PLM with the development lifecycle, we needed to align to the development methodologies, which are, as you guess, or which is, as you guess, agile. So we're looking at the agile. We looked at the agile principles to see how they can come to our benefit. And this is what we found. Principles like short cycles, rapid delivery, continuous delivery, and immediate response give us stuff like reduced time to market and short turnovers. Principles like transparency, empowerment, sync ceremonies like dailies and scrums and early detection give us improved quality and improved reliability and also improve our forecast for cost and timelines. Principles like prioritized backlog at all times and MVP give us an option to give the customer exactly what they need, right? So we're not just effective, but we're also efficient. And in addition, it gives us an option to keep the customer advantage if something changes in the market. Principles like cross-function collaboration give us maximized supply chain cooperation. But, you know, there is a misconception that agile is an hierarchy. The endless iterations give you a feeling that you can endlessly revisit scope. And if you don't make it on time on this print, you can always postpone to the next print. So we needed a framework to combine the PLM principles with the agile principles. Something that will align to the dev life cycle, something that will align to the security life cycle. Something that will give us pace, heartbeat and milestones. So this is why we defined our own product life cycle management framework. And this is the framework we defined. Okay? As you can see on the purple background, we have the product life cycle stages and on the blue background, I don't know if you can differentiate here, and on the blue background, you have the dev stages. We want to show you how we align them. So first of all, in the inception stage, as I said before, this is where we conceive the product. We also do the market research and the competitive analysis. We define the vision and the strategy, and the development does not have a corresponding stage here. But then when we get into the definition stage, as you can see, we combine the definition and the planning stage, which in the PNM were two different stages. Here we combine them. We aligned it to the planning stage of the development. It's where we break down the themes and break down the features, do the priority, talk a little bit about high-level effort estimates. Then we get into the design stage. The design stage is the big circle. This is where we break down even more to user stories. Talk about the UI and the UX. Get down to the practical stuff. And of course, the correspondent development stage is the dev and the QA, where we manufacture the product. Of course, in reality, it's iterative and it's done upon some sprints, not just one, how it looks here. So as I said before, this framework is easily adjustable to other frameworks like the dev framework and the security framework. Let's talk about secure development and lifecycle management framework. It's a, as I said, we need framework to ensure that we have all security controls embedded on proper development stages. So we created this framework. We presented it exactly one year ago on our previous talk. So I'll just shortly remind you this main idea of this framework. You possibly familiar with such frameworks from Microsoft or maybe Oracle or other big vendors. So what we do, we just command security activities on relevant development stages. For example, the performance security plan on planning stage, the trade modeling and design stage, et cetera. Even this framework was built originally for big legacy products with wonderful development. We quickly understood that we need to adjust this framework for modern reality. And modern reality is agile development. So the simplest way as Microsoft, for example, did, they create a separate framework for agile SDRC. In our case, we already have the framework fully embedded in our organization policies and processes. And so we weren't so flexible. And we just started to study deeper the agile principles and understood that we can take exactly same activities, make them shorter, more lightweight, and with faster return and run them iteratively. So we didn't make big changes in our framework. We just adjust our activities according to agile principles. So maybe you're asking yourself why do we need this? We are big believers in the embedded of security on early stages of development. So how many of you already heard the term shift left? Do we have someone who didn't hear it? In any case, we prepared this slide so we have to remind you about this importance and meaning of this movement. So historically many organizations started the security program in reactive order. It means someone who didn't hear it. It means that. I'm just wondering, everyone can hear Elena because she's a little bit far from her. Just remind the situation. You want to build something. You came to construction company and they say, I do not care about fire protection. We have fire department. Call them when fire starts. You seem to have a very old approach. It was once upon a time. We just had a conversation with one product manager. Fortunately, not from our organizations. And he said, why aren't we here about security? We have security department. In another word, call them when fire starts. So many organizations already understood the problem and started to implement security activities before release. But after, all development finished and all got fully implemented and all resources moved to next release. The shift-left movement, let's move to the big circle. This is our endless iteration cycle of design development and test. And many people think if we are there with security activities, the mission is accomplished. Yes, it's a great achievement. It's a really great achievement. But we want to be even left. We believe that planning is a crucial part of any successful security program in organization. If I continue the analogy with the construction, we want to be here when we plan the building even before the first drawing started. Because it might affect your material selection. It might affect the amount of windows and doors you need to create. It might affect, I don't know, supply location and maybe you need to have proactive controls such as sprinklers, for example. So SLM is our answer on this demand. We use both frameworks in the same, exactly on purpose. Because we want to say that ideally, someday we will have only one framework, Product Secure Life-Econ Management Framework. Let's say this again, Product Secure Life-Econ Management Framework. Meanwhile, from different reasons, organizational, cultural, tools-wise, these two frameworks exist in parallel. And our goal is to connect the corresponding stages of these two frameworks and attract the attention of product manager to make him or her a real security ambassador. So how do we achieve the connection points between these two frameworks? So first of all, of course, we need to identify the connection points of the two frameworks. Then we need to align the activities that happen in these connection points. Then we need to define the responsibilities and deliverables of everyone. And then we need to track the progress, of course. So we wanted to make the security element an inseparable part of the product lifecycle management. So what we did is created neutral checkpoints. Now, you might remember from our previous presentation that we had five main checkpoints when interacting between security and development. You can see them there. When communicating between security and product management, we have only three checkpoints. You can see what we have in every checkpoint in every one of the disciplines, the development of product manager and security. So three checkpoints, that's less than five, which makes it easier and less intense for you to adopt, right? So let's dive in into the checkpoints. So first, we have the kickoff. The kickoff is actually our first all-hands meeting, where all the governance team meets together. What we do here is we briefly talk about the roadmap in terms of content and timeline. Then we dive into the upcoming release, and we talk a little bit about the features explaining what we mean. We talk about the timeline, and of course we talk about the definition of done of this release, the release criteria. And let me underline that security criteria is part of the release criteria. Also, we talk about the capacity and effort estimates in high level, and we make sure we have a security bucket in place. As you remember, this is done in conjunction or just before the planning of the dev, so we make sure we have a security bucket, and we ask the security team to get back to us with any inputs or efforts that can affect the dev team. We think this meeting is very, very crucial in laying the expectations from the product manager side, where I lay my expectations, from the governance forum, the dev, the QA, the security, the marketing, the documentations, the operations, and this way I create a core team that works together towards a common and clear goal. How do we do this? Well, it's a scheduled meeting. We have a presentation template. In the presentation, of course, we have all the tasks aligned with due dates, and for every task we have a governance team provider and a governance team consumer. And of course we also have our planning tool in which we do the capacity calculations and the effort estimates calculations. So just to give you an idea, this is not exactly how it looks, but just to give you an idea of some screenshots of what we do. So this is the roadmap for 2017. We look at how many releases we will have, how they're aligned with sprints, when we have the stagings, and go live. This is a drill down to the upcoming release. As you can see, we can see when we have the kickoff, the sign off which I will talk to you about, and the design state which, oops, I'm sorry, I will talk to you about. We can see when that happens. Then we have the tool of the governance team. As you can see, we have focal points from all the disciplines, product marketing, pre-sales, and R&D, and etc. But what I underlined here is that we have the security focal point as part of the governance team. And Elena, of course, is that focal point. I had to raise all the other names. In addition, we have our planning tool which we use Excel for anti-planning, and of course the features effort estimates per team and with priority, of course. So just to tell you here, you can see that we have a lot of tools. But this shouldn't stop you. The main tools is because you know in an organization every discipline uses another tool. But this is a challenge, but we still do it. And we want to show you where there's a will, there's a way. So the design stage that comes after the kickoff. You might remember this is the manufacturing point. This is where the DEV and QA and security meet to manufacture the product. Okay? So here what we do is the product keeps getting more mature and detailed input into the R&D teams. And it is where the input gets into the factory and is digested by the DEV teams and QA teams and also the security teams. Now here in the design stage we have the five checkpoints that we talked about before. We have bi-weekly ceremonies between DEV and security that we talked about in our former talk integrating security in agile project management. Now if you didn't hear that you can Elena will dive into that shortly and she will illustrate how if you bring in the product manager into these joint checkpoints between the development and the security team in the main development stage you get the business on your side. This is real-time prioritization. You get resource allocation changes if needed and you get waiver's approval review maybe if you need them and risk approval review if you need them and you get an engaged product manager in the main stage of the development. I would like to deep dive now in the security bi-weekly meetings that we have. Now we will have short flashback and we talk about this too. Three checkpoints we have in development and security process but as Fred said these checkpoints always come in coordination with product manager because we do a lot of activities here content review, threat modeling and security assessment and any of these activity might lead to content changes. For example, threat modeling might lead to complete feature redefinition or just add a couple of new user stories to it. So let's take a look at the checkpoints content review. I'm sorry, the two clicks. You see RPM has all resources and we need to coordinate with them. So first of all content review. What we are doing on content review we perform security impact labeling. We take all new content, we do this iteratively every time when new content inserted in the release we are doing the security impact labeling. This help us to identify most recommendations to our release and concentrate on them. The activity performed by security with and developer for components. At the end of the activity we have very variable outcome we know complete picture of the release from the security perspective. We have prioritized backlog item list for security assessment stage we will talk about this later and we have candidates for design review very important activity which we are running continuously. So design review this is developer friendly name of threat modeling and it's not only light of pronunciation but we also running it in the lightweight mode. Because according to agile principles flexibility MVP and fast turnover we need to perform this as soon as design of the feature started. So we have our own methodology of threat modeling. I cannot elaborate it here due to the time restrictions but in general what we are doing we split this feature on different data flows put these flows in 9 security patterns we define such as authentication, authorization, security communication etc and apply theoretical threads on every flow in every pattern. And the end of the activity we have list of theoretical risks which might be inserted by this feature and development teams admitted relevant user stories already define the feature accordingly. And as I said it must be done with coordination with product manager because it requires reprioritization and my very definition of the content. Next very important security activity this is security assessment this is manual for penetration testing we are doing when feature is done it provides us confirmation that code implemented properly from security perspective the agreed mitigation were implemented and no new vulnerabilities were inserted. This activity done by penetration tester experts external or internal external might be third part you can invite on demand contract risk we have penetration test is different from the classical penetration test which I did doing upon product deployment because we very restricted time, we very focused so we selected the white box approach it means our expert have full access to product inside such as direct communication with development team or even code access Any case security assessment is very important it's always done when feature is done because you cannot run penetration test when feature is not functional so and as I said the code manager principles we need to fast turn over so our recommendation approach is to automate security assessment as well you can use any security assessment tool such as static analysis, dynamic scanner, third party scanner, infra scanner in any combination in your own timelines it means you receive feedback on almost every code change or configuration change or dependency update we raises this topic here because again this is very powerful tool but requires resources and budget so you should have product manager on your side to successfully embeds your commercial project in your development life cycle and finally we have the sign off that's the third checkpoint now I want to tell you something about these checkpoints these mutual checkpoints are very very critical for the communication because it is where we can identify together with the governance team all the gaps and risks and we can find the proper measures to fix them so the sign off is the release status this is where we get the big picture we look at the release criteria the definition of done we check our KPIs we look at the bug numbers and we look that it doesn't exceed the release criteria we look at all our risk assessment forms aka waivers that they're all signed we look at our security grade as I told you I'm talking about the release criteria more but of course we look at the general release criteria and of course we also have statuses during the release but that's a project management role I'm not talking about that now I'm talking about only the product management checkpoints so the product management the manager gets in here in the sign off and gets the full picture all this data is presented to him and he can compile he or she can compile all this data and according to the benchmarks and standards in our organization decide if there is a go or no go to the release how we do this we also have a scheduled meeting we also have a presentation and we of course have a meeting and see that all the forms are signed so I just want to show you screenshots again of the release security release criteria because that's what our talk is about of course we have more release criteria so first of all we have the executive summary where we can see how many critical high medium and low items we have and of course calculate our security score then we have a form that tells us what level we need to have approved that security score which is me can be an SPM, a VP a VPBM or whatever and we have the acceptance risk form the waiver this is another form here you can see only the first page with the process of the risk acceptance that the product manager has to undergo an answer in order to either approve the risk or return it into the backlog as an action item of course now we can't show you the whole form and put it in their presentation this is just so you can read the process that a product manager has to do in order to accept the risk and to tell you that we have such a form and we advise you to have such a form too and I think that's it that's the final stop in our journey and the mutual checkpoints but why is it on form? what's the weapon? the weapon, what's in it for me or you? what's in it for me for you we gain information, information is priceless we have the information about the upcoming release and information about the roadmap at all and we got it earlier at the right place and right time to raise the security concerns, requirements and depths from the previous releases from the front point of view we also get information information from the security, from the development and we can plan property we can manage the risks and we can control the consequences and from the products side of course we have the continuous alignment of the team and the continuous alignment of the content which gives us flexibility that's not me which gives us flexibility and proper risk management and we have even more we will not drill down in every each of them because we have something more important that's the company shared with us we have stuff like cost reduction efficiency, short turnover collaboration, quick maintain customer trust increased revenue, increased quality decreased reduce, compliance innovation, team cooperation shared goals and in short money and at the end we want to provide you some general recommendation which you can take with your home and try to implement in your own organizations so first know your partner know your partner's limitations timelines and methodologies find the common language define the shared goals take responsibility get out of your comfort zones and be each other's ambassadors make your all activities to reach this unicorn product secure life cycle management framework meet and sync periodically have joint mutual checkpoints don't close your eyes, communicate listen and break the wall use tool ensure that all your decisions are audited and finally formalize and brand yourselves in what you're doing infuse security awareness into product management in your organization and finally we want to leave you here today with a precious quote by Benjamin Franklin a quote that we think best represents the shift left movement which we are so passionately promoting in all our sessions an ounce of prevention is worth a pound of cure and even more if you will go to bed winter is coming for those of you thank you questions yes, first of all I have a compliment being with Nora sorry you're right said that as a product manager it's quite abnormal for me to have a security awareness and to get interest in security and what was it that raised my security awareness so I said I take it as a compliment that I'm abnormal so the truth is it was a process Elena did this when I first met her and I saw the passion and I saw the seriousness in which she treats this I don't know, something just got me and then we started to work together and invented this process and we saw that it worked and we saw that we got better security scores than the other groups we saw that we're preventing stuff there are many many times where we saw that we needed to mint the architecture and the feature design so it's only the practical tips and stuff that we did that made me security aware but again I just fell in love with Elena from my side I had a lot of meetings with product managers on every label pretty similar to the first scene but we broke the wall at the end but we have the successful process yes how much has this filtered out so you can say in the HB how much has this filtered out that was the question how much other groups do this really in our organization it's a common process for every product we're developing in our business it took us four years but yes it took I'm at the position more than four years it was a challenge here we have people who know this was a challenge but now we succeeded to invest in our business unit in every leaders I must tell you that I'm working at Intel now I worked together with Elena for four years in HB and also our previous talk about integrating security and agile projects as a project manager and now as a product manager I take all these tools and insert them into Intel so I can tell you it's also starting to work in Intel but it's a small scale right now but I'm working on it in my group so yes the question was how long do the development cycles have to be in order for this to work so I can tell you when I work with Elena you can say what happened after I left we had the development cycles of a release every two months and we've also done this started to do this in a release every month so it can be done sometimes we do the security assessment and tests in major releases like not every month but in three months but it does work in two months I can guarantee I can say it worked even one month releases we have a couple of products with monthly deliveries meanwhile we don't have something short we currently investigate the possibility to work with agile principle feature based feature done, feature tested, feature closed but it's we are not still there we are doing security impact and threat modeling on feature based but a security assessment is going for every new content inserted plus main patterns as I said we always check authorization, authentication, communication that it's not affected by new content I think you also if you get the security ambassador within the team you can talk about it you have your security champion within the team, it's a developer that is responsible for all the security elements maybe you can do this also in user stories and bugs and take it even to smaller deliveries like in two weeks but what we've practically done is one month it would be interesting to try yes how many projects get one security person living far away the question was how many security how many projects get one security person doing parallel that's not the best person to ask yes, agile based agile based currently responsible about four products running in the fast delivery mode and about four products in legacy waterfall mode with half of year delivery in case it's hard to meet more people yes you need more people well, Elena is not our we get hearts here from our team yes any other questions, yes sorry again, the delivery time what is the difference between the delivery time when we do agile based delivery and their regular waterfall delivery so I can tell you and then we'll give you from her groups I can tell you the waterfall delivery we've had one delivery in six months or in a year and with agile we've been once in a month and once in two months any more questions great, thank you