devopsy.kinsta.cloud

Tag: risk management

  • Managing Business Risk in a DevOps Context

    Managing Business Risk in a DevOps Context

    We hear a lot in the industry about the importance of automation in DevOps to enable speed. However, there is another element that is often missing in the discussion – risk, compliance and security. Traditionally we have a zero-sum approach, where we need to either go fast or be safe and secure. It’s one or the other. Or, maybe not! There is an 80%-80% middle ground to consider. Balanced development automation is a natural evolution of DevOps; it is not just about the technical side anymore, but also includes the risk and the compliance side, as well.

    Aligning Executives

    How do we get business executives and risk executives, at the strategy level, to align on this idea of balanced development automation? First, it is important to realize that what represents a risk for businesspeople is different than the risk that’s perceived by the development group.

    For example, let’s say there is an urgent requirement for some sort of additional business functionality in response to competitive action, or even in response to a pandemic. From a business standpoint, risk might represent a failure to deliver an effective solution within the particular timeframe required. From an IT standpoint, concerns about risk are likely going to be different from the business risk.

    That being said, it’s a futile exercise to convince business management to think in terms of perceived IT risk as opposed to business risk. IT must be able to translate the risks of their development work into business risk, or management may not see the potential impact of that risk. And so, pressure remains to “Get this thing done as quickly as possible!”

    Even at the executive levels, there is a discrepancy in identifying what risk really is. That is true at similar management levels at different organizations, even within the same industry. Let’s look, for example, at the whole issue of security and how much effort we should be paying to validate the security of a system that we’re putting in place, or that we already have in place. If an organization has experienced a breach, they are much more likely to have a management team that is concerned about security. In a different organization that has not seen any security breaches, they may not be paying as much attention or making the appropriate investments to make sure systems are secure.

    Aligning DevOps and Security

    We also need DevOps engineers and security engineers to align at the tactical level. So how can these teams, that are typically at the program or project levels, integrate and think about balancing development speed with risk and security? Operational teams are very important in achieving balanced development automation. If we look at the risks from the perspective of the development team, it doesn’t matter what technology you’re using to develop an application, or even if you’re implementing someone else’s application.

    From an IT standpoint, one of the most likely risks is failure to deliver functionality of the particular project that you’re doing. That is an example of delivery risk, which senior management is very concerned about. The way that tends to manifest is in delayed delivery or allowing the business to change their mind during the particular project. The risk of not delivering the functionality that’s required is increased. The process is just going to crack simply because the project has not been managed effectively, requirements were not stabilized or adequate testing was not done.

    That is an extremely high risk that development groups need to be aware of. A development group needs to apply some type of balanced methodology and minimize the likelihood of a gap between the expected outcome of the project and the actual outcome.

    Demand for Balanced Development Automation

    Today’s business context demands both speed and some awareness of risk from development teams. This will only be achieved through alignment at the executive level and at the tactical level. Focusing on areas of business risk are essential to achieving this alignment.

  • Cloud Migrations Demand Risk and Compliance Maturity

    Cloud Migrations Demand Risk and Compliance Maturity

    The COVID-19 pandemic brought undeniable disruptions for organizations and their employees whether business, personal or otherwise. Across the globe, businesses and governments alike were forced to try and manage these disruptions. For nearly all organizations, digitization initiatives were accelerated in a short period of time, from implementing work-from-home policies and launching new applications to support a distributed workforce to adopting artificial intelligence (AI) to adapt supply chain processes and more.

    According to Gartner, by 2022, 30% of all security teams will have increased the number of employees working remotely on a permanent basis and by 2023, 40% of all enterprise workloads will be deployed in cloud infrastructure and platform services. The distributed cloud enables organizations to provide products and services when they’re needed in this era of work-from-anywhere, whether to their employees or customers.

    Even in sectors such as energy and utilities, which are historically heavily reliant on standard on-premises installations and had often avoided cloud adoption, business leaders are realizing the value of migration, especially in light of the global pandemic. These businesses are able to deliver digital products with speed, experiment with tools such as artificial intelligence (AI) and robotic process automation (RPA) to increase productivity and to lower the total cost of ownership (TCO) across assets, among other benefits. Still, cloud migration risks abound, and new challenges may arise. A risk that cannot be ignored is the cybersecurity risk. Meeting regulatory IT compliance and managing risks involved with cloud computing are top challenges facing those migrating their workloads to the cloud.

    Cloud Migrations and Security: Clear Risk and Compliance Gaps

    Many cloud providers such as Microsoft Azure, AWS, Google Cloud and others have a global network of service models that include compliance teams and consulting organizations that help with risk and compliance for their cloud instances, whether public, private or hybrid cloud. Many of them have even built tools for customers to use to implement basic risk and compliance management in-house, leveraging relevant data and applications. However, monitoring and meeting security and compliance controls that span people, processes and technology for cloud environments, and in the broader context of the enterprise, is complex. This is one cause of cloud migration risk, and is a challenge for many other reasons; lack of measurement, visibility and accuracy are three of the greatest risks when migrating to the cloud. The point solutions that currently support most cloud instances don’t elevate the posture of cloud environments to that of the enterprise risk posture, and the majority of assessments still remain point-in-time and qualitative. Metrics are fractured and far from holistic, and very few, if any, solutions can provide insight beyond compliance and into real-time risk management.

    IT and security regulations and standards are filled with requirements that were created before the cloud became a commodity. In the energy sector, for example, cloud security isn’t taken into account because regulators and industry leaders couldn’t fathom those platforms becoming as pervasive as they have, because on-premises installations were standard to the industry. On-premises installations are still a mainstay in energy, power and utilities, and for those who have become more comfortable with cloud migration processes, there is a clear and pressing need to leverage their human capital, processes and technologies to implement robust risk management practices.

    Beyond regulatory compliance lags, many distributed organizations opt to have multiple providers in place, requiring a multi-cloud approach to compliance requirements and risk assessment. As more organizations consider cloud migration risks and begin shaping their cloud migration strategies, there are some innovations that address risk management and compliance in the cloud, but not many. Measuring, managing and reporting on compliance frameworks, making the shared responsibility model actionable, and getting a view into risk are all serious challenges. Cloud providers will continue to mature and bring new innovations to their services, but, to date, there hasn’t been a lot of anticipatory work done in this area. The focus has largely been on creating reactive solutions. In heavily regulated countries, the challenges only become greater.

    Leverage AI Automation for Compliance and Risk Management

    There is a shift occurring in cybersecurity and IT risk management, calling for the dramatic disruption of the legacy IT governance, risk and compliance (GRC) space and demanding a reevaluation of how we manage compliance and risk in the digital age. For years, data has been aggregated manually and analyses performed on out-of-date information. With the increasing availability of automation, the five functions of the NIST Cybersecurity Framework – identify, protect, detect, respond and recover – are becoming more continuous in nature and shifting into real-time management, from assessment to reporting and more.

    Leveraging this technology in the cloud is no exception, but those who look to reinvent their approach must look for solutions that go beyond the siloed capabilities of cloud security posture management solutions and similar markets.

    Ultimately, the true test of this next-generation approach comes when organizations are able to roll all of this data up to risk. With risk metrics that are supported by drill-downs, trend reports and risk profiles, executives can get the visibility they need into their posture with the most up-to-date data, informing their key business decisions. Using this next-generation approach to risk will inform global expansion, allow executives to evaluate risk across lines of business, and increase cyber maturity in any cloud-based organization.

  • Managing Data Risk in 2021

    Managing Data Risk in 2021

    You can’t protect your data if you don’t know where it is stored. The first thing to consider when creating a risk-based approach to data protection is the ability to identify and prioritize data, and control who has access to it. But, how do we do this? How do we prioritize data?

    In this TechStrong TV episode, Ron Bennatan, senior vice president and general manager of data security at Imperva, joins Mitch Ashley to discuss privacy, compliance and managing data risk in data lake environments in 2021.

    The video is immediately below, followed by the transcript of the conversation. Enjoy!

    Transcript

    Mitch Ashley: I’m very happy to be joined by Ron Bennatan, who is GM of Imperva Data Security. We’ve talked before—Ron, it’s good to be speaking with you again.

    Ron Bennatan: Hey, Mitch. Nice to see you again.

    Ashley: As always, yes. Data and security—two of my favorite topics. [Laughter] Welcome to 2021.

    Bennatan: Yeah, 2020 finally is over. [Laughter]

    Ashley: Ooh! You know, it takes a pretty big rearview mirror to look at that, but I’m not sure I wanna look back too much. [Laughter] Well, we’re gonna be kinda talking about looking forward into this new year. First, would you introduce yourself, tell us a little bit about you, and also a little bit about Imperva?

    Bennatan: Yeah. So, Imperva is kind of the market lead for data and application security. We secure all paths to data. So, it kind of straddles between both covering how data is accessed and where data is accessed, kind of covering everything regardless of on prem and cloud, hybrid cloud.

    Ashley: Mm-hmm.

    Bennatan: And I am the GM for the data security side, and really glad to be here.

    Ashley: No small problem you’re solving. [Laughter] Data is everywhere, you know?

    Bennatan: One problem, yeah.

    Ashley: [Cross talk] data. At least not very many of ‘em. So, let’s talk about it. I mean, you know, we have the whole government breach in 2020 Russia—you know, Russia, Russia, Russia, that whole thing.

    Bennatan: Yeah.

    Ashley: It certainly brought a lot of attention to supply chain attacks. Of course, you know, that being an intelligence brief, it’s collecting a lot of data, right? You know, that could, of course, happen on a—it is, did happen on corporate networks, it could also be for financial gain; it doesn’t mean it has to be a national state attack. So, I imagine that’s gonna be a—supply chain is a word we’re gonna hear a lot about this year.

    Bennatan: Yeah, I think so. I think, you know, as a, just an individual, my fear, by the way, is—you know, there’s a really big project coming for the entire world, which is the delivery of the vaccines, and that itself is a supply chain. I just hope nothing messes up there, you know? Like, you know, knowing that whatever vaccine you’re getting is actually the valid one and not—you know, there’s a lot of…everything is in data and everything at the end sits in some kind of a, like, what’s the lineage of something? What’s the providence of something?

    Ashley: Mm-hmm.

    Bennatan: You know, it doesn’t necessarily—you know, we in the data governance area talk a lot about providence and proving the correctness of data, but you know, it goes all the way to the vaccine as well. So, I think this issue that we’re seeing, whether it’s breach—breaches get headlines, okay? And, you know, so this SolarWinds thing gets a big headline, the thing that these attacks on MySQL with ransomware, that gets headlines. But really, the bigger issue is getting control of our data and creating kind of a complete risk oriented approach, not just plugging a hole here and plugging a hole here and plugging a hole here. It’s—that’ll never work, right? It’s much easier to create a new hole than to plug all the holes.

    Ashley: The whack a mole strategy. “Here’s another mole to whack.” [Laughter]

    Bennatan: The whack a mole—yeah, the whack a mole doesn’t work. Whack a mole doesn’t work. And especially today when the complexity of the data environment is so much greater.

    Ashley: Mm-hmm.

    Bennatan: You know, 20 years ago—okay, 40 years ago, we just had some dashboard on the mainframe. Twenty years ago, we just had Oracle sitting on some Unix server. Today, it’s such a complex environment, data moves from place to place, you know, you look at what a data lake implies. It’s no longer a single stack, it’s a combination of stacks. Whack a mole doesn’t work.

    Ashley: Mm-hmm.

    Bennatan: So—and most companies understand that. Most companies are in this process of investing in a non-whack a mole approach, in a risk based approach that says, “Okay, I need to know where my data is. I need to prioritize which. You know, not all data is created equal. I need to scan, I need to understand, I need to know who has the ability to access something. I then need to know who is accessing something. I need to control what they’re accessing.”

    So, you know, I think there’s a better understanding that whack a mole doesn’t work.

    Ashley: Mm-hmm.

    Bennatan: I think 2021 is still gonna be a transition year. I don’t think we’re gonna necessarily get there, but we’re gonna transition.

    Ashley: We won’t have universal enlightenment [Laughter] on day—

    Bennatan: It just takes time. I mean, it takes time.

    Ashley: It does.

    Bennatan: There’s a lot of data.

    Ashley: I wanna ask you about—you did a nice job of kind of outlining, you know, identifying what data you have, prioritizing it, access to it. One of the things that I’ve always struggled with is that second step. How do you prioritize? What are the things to consider? You know, there’s obviously sorta crown jewels of my business—this is the customer data or secret sauce or that kind of things, but is there a good sort of stratification of how to prioritize data?

    Bennatan: Okay, there’s a technical answer and there’s a human answer.

    Ashley: Okay.

    Bennatan: Okay, technically, there are very good ways to do this. It takes some effort, okay? You can—you really do this based on a scoring of a bunch of dimensions, okay? So, one dimension could be the sensitivity level of the data, okay? Another dimension could be, what is the impact if something happens, okay? Which—but the reality is that we’re all people, and people are driven by incentive, and incentive is not necessarily, doesn’t always necessarily create the right prioritization. It creates whatever prioritization the incentive is structured around.

    So, I’ll give you an example. A lot of projects going on around privacy—a lot of projects. Because it’s a very, it’s a relatively new thing, less understood, and people don’t always equate the fact that we have been doing the work, almost the identical work, we just didn’t call it privacy, right? We called it classification.

    Ashley: Mm-hmm.

    Bennatan: But when you look at what privacy implies, it’s the same, but very new terminology—different semantics, different terminology. So many people don’t start from an investment they’ve already done in the last five years, they start from scratch, and the incentives are created because there’s a new role in the company. There may be a new—you know, a data privacy officer, okay, and that person has certain mandates and they drive things top down.

    And so, I think that the reality is, prioritization is driven by the projects and the funding that these projects have, and they’re also driven by breaches, okay? Because breaches are very dramatic.

    Ashley: [Cross talk] response, right? [Laughter]

    Bennatan: Dramatic, immediately created. So, I think that the reality is gonna end up somewhere kind of in the middle where things are gonna be driven bottom up and top down and they’re gonna meet somewhere.

    Ashley: Mm-hmm.

    Bennatan: But it’s not terribly complex to create a good prioritization strategy, but it’s not trivial, either.

    Ashley: Yeah, you definitely have to put some thought into it, and it’s not a textbook exercise, right? It’s all contextual.

    Bennatan: Yeah.

    Ashley: What’s important to the business.

    Bennatan: And I think you’ll find in—I mean, my prediction in 2021 is that there’s gonna be a lot of, you know, privacy is not gonna just drive a lot of these from a compliance perspective. Okay, until now, privacy is really—you know, when a company embarks on these privacy and classification projects, or at least what I see from our customers, is that it’s driven a lot by compliance, okay? They need to comply with a CCPA, they need to comply with GDPI.

    Ashley: Mm-hmm.

    Bennatan: I think we might end up having also, like, an attack flavor, okay, around privacy, which is not intuitive, not necessarily intuitive. And it has to do with the fact that, you know, part of the mandate is, you know—so, say that I am, you know, year one of my consumers and you store, I store some of your data. That means I—you have the right to demand some things from me. Like, you have the right to demand that I delete you from my system.

    Ashley: Mm-hmm.

    Bennatan: You have the right or portability, you have the right to ask me what data do I own or do I store about you? And you can come to me with these requests, okay? Different terms, different subject rights request or data access requests. You know, you can easily think about what is the effort that I, as a big company, have when you ask me to do this? It’s not a small effort. So, okay, if you—now, the nice thing is, most people don’t do that, okay? I’ve never called somebody up and told them, “Hey, delete me, okay?”

    Ashley: [Laughter] No, I think that’s probably very much an exception—maybe a rare exception.

    Bennatan: Yeah, but what happens is some people realize that this is the way to cripple a company.

    Ashley: Mm-hmm.

    Bennatan: What happens if they organize and they say, “Hey”—

    Ashley: Or protest, right?

    Bennatan: – protest, you know?

    Ashley: Moving of Facebook onto whatever.

    Bennatan: “We don’t like you, let’s organize 10,000 of our friends and we’ll all hit them at the same time.” What do you think that’s gonna do from a work perspective? It’s pretty serious.

    Ashley: Yeah, I’m guessing it’s not just press a button—that’s gonna consume some resource at the company, people resource, things like that.

    Bennatan: Yeah.

    Ashley: You know, one thing I was wondering, too, is, with this year, there’s discussion now about do we need a national cybersecurity strategy, things like that, just to mention politics, the Biden administration is talking about working with other countries to establish sort of norms of what we do when it comes to cyber whatever with each other and what is considered an attack.

    It seems like that is—maybe not this year, but that’s certainly potential for regulation of those kind of discussions, whether it comes out of any national strategy or not or could be another country that says, “Okay, now we’re gonna take this to the next level.” Like, what is our position around data? Not just privacy, but if it’s compromised, then what happens to you as a firm? I mean, it could get kind of interesting.

    Bennatan: Yeah, it could. You know, I mean—again, we’re delving into, like, opinions and politics.

    Ashley: [Laughter] Yeah, I know.

    Bennatan: I’m not a fan of—I’m not sure that something like this could go that route. But I do think that it goes other routes. So, for example, like, I’m reading a book on kind of the history of the Mossad, okay, the Israeli intelligence service.

    Ashley: Mm-hmm, mm-hmm.

    Bennatan: And you can see—and whenever you read any of these books, you see that all of the intelligence community, they have back channels, right? They agree on things.

    Ashley: Right.

    Bennatan: So, to me, if we wanna have something like that, it should be, like, the cyber czar of the U.S. and some other—you know, the big players, they have to agree. It doesn’t need to be regulated, it doesn’t need to be at the politician level, it has to kind of stay at the—

    Ashley: Kinda behind the scenes with the cyber czar.

    Bennatan: Behind the scenes with the experts at the—but, you know, there’s definitely an issue with state nations, okay? This does need to be addressed. Now, you know, it’s not necessarily that every—you know, we always think that, you know, we’re the good guys, they’re the bad guys, you know?

    Ashley: We would never do anything like what they did to us, right? [Laughter]

    Bennatan: Well, you know, there’s examples in history, okay, of things. So, I do think this is coming. I don’t believe it would happen at a politician level, it will happen at the actual subject matter experts. And by the way, there are good examples of things that have happened like that, especially in the financial services community. I mean, for years, maybe even decades, you know, FS-ISAC, they work together to create some level of standards across investment banks or banks. These things work, I just don’t think it’s political.

    Ashley: Interesting. Well, I wanted to kinda tap your thoughts on that. I know I threw the line pretty far out there in the water, [Laughter] just to kinda get your thoughts on that.

    Well, let’s reel that back in a little bit and talk—you know, there’s GDPR and CCAPE for California. A lot of people are still in this, I think in this kinda implementation stage, even though we’re supposed to have those things all covered, right? Maybe a little farther along with the GDPR, of course, but is that something, this year, you think it’s—we’re in this, okay, let’s now institutionalize some of those things in the organizations and really take care of our knitting there or do you think there’s more things on the horizon that are gonna come at data people?

    Bennatan: I think it’s gone into an implementation phase, for sure—which is good.

    Ashley: Mm-hmm.

    Bennatan: You know, there’s a lot of things, many things are not terribly clear, by the way, even though it’s in implementation. I’ll give you an example, right, this notion of being—my ability to request that you delete me, okay? But let’s take something else, which is a different type of compliance requirement, which is for you to keep logs for a certain period of time, activity logs. There are a whole bunch of other compliance requirements that require you to do that.

    Ashley: Data retention requirements, yeah.

    Bennatan: Yeah. Okay, so—now, what happens if part of the activity logs has my identity in it and I request you to delete it?

    Ashley: Mm-hmm.

    Bennatan: Should you delete it, or should you not delete it? One, in order to comply with one thing, you should delete it. In order to comply with another thing, you can’t delete it, maybe for three years. So, there’s even things like this, which are conflicting messages. And at the end of the day, it’s going to depend on some level of interpretation.

    Ashley: Mm-hmm.

    Bennatan: Which, at the implementation level, I can tell you, I can see two approaches. One is—okay, this interpretation needs to be given by legal or it’s okay for the business to give the interpretation to that. So—and you know how it is. If it goes to Legal, it takes a longer time; if the business can make the decision, then it goes much faster. And I’m seeing more and more of this moving to the business, taking ownership, and making the decisions, in which case, it goes much, much faster.

    Ashley: Well, and oftentimes, it seems that that always happens with laws and regulations, right? There’s what it is and there’s the interpretation of it, and there’s sorta those middle tier organizations, the consultants, the larger firms to sort of establish the frameworks that, “This is our interpretation of it,” so if you do that, you’re sort of in the norm with what the industry is doing. Who knows if that’s the right interpretation or not? It’s always subject to change, but that’s usually where that help comes from, at least on the big thing.

    Bennatan: Well, yeah. I mean, it starts from there and then usually what happens or what it evolves to, which makes it really go much faster, which is what’s happening now is that if—and by the way, it goes back to your question about this nations coming together or an industry coming together. The minute you have some critical mass within a certain peer group and you say, I don’t know, maybe I’m an insurance company, if my peers have taken upon themselves a certain interpretation, I usually don’t even care where they got it from.

    Ashley: Mm-hmm.

    Bennatan: Maybe they got it from these consultants, maybe they didn’t. But if three big players in my industry are doing the same thing, I’m gonna do the same thing.

    Ashley: Yeah.

    Bennatan: And that’s what’s happening now is that, you know, I know the insurance industry well and I know the banking industry well, and I can see that they’re now, “Oh, we’re gonna do like them” and then it’s much easier to follow, like, a track that seems to be proven than to try to invent it. And that’s happening and that’s why I think there’s an acceleration for a lot of these things.

    Ashley: Yeah, I agree with you. That makes a lot of sense. What are your other thoughts about 2021? What are we gonna be thinking about that we didn’t realize is gonna be on our radar for this year?

    Bennatan: I think we are going to kind of understand this notion of, you know, look at the data from every way that you can get at the data, not try to—like, historically, there have been a focus on pillars or silos, which were more and more, or in the past were driven really by tool specialization, okay? Like—okay, I’ve got the DLP and I’ve got this and I’ve got FAM and I’ve got databases, and I’ve got big data.

    And today, the lines are so blurred, especially on the cloud services, they’re even more blurred that there’s starting to be a realization that we really need to look at all paths to the data and all ways to secure the data and look at it instead of individual silos, looking at it as, “This is my data fabric.” Okay, so you’re starting to hear things like, you know, data lakes, data fabric, data services, and the data service could be structured by different implementation stacks. But you’re no longer trying to secure each stack by itself, you’re trying to secure the entire fabric.

    Ashley: Mm-hmm.

    Bennatan: And it’s really the right thing to do. It’s the right way to think about it. It is something that requires a transition, because even organizationally, many companies had one group doing this and one group doing this and one group doing this. And this notion of, you know, looking at a single overlay control layer, okay, which can drive policy down or can bring things up is, you know, it’s time for that. And I think 2021 is gonna be, part of this year is going to be starting to deliver things at that level of abstraction, and it’s also enabled by the fact that there is technology that can kind of bubble everything up into one level, right? You don’t need to look at it as 20 different tools, you need to look at it as kind of like a federated layer, and at least it’s doable, right? Ten years ago, it wasn’t doable to do any of it.

    Ashley: You know, it’s interesting. What it makes me think of is maybe some norms that we’ve had for a while of thinking about data owners, and that sort of puts the blinders on of, now I create that vertical view of, “This is that data for that purpose for that business unit for that application or process, whatever it might be.” And what you’re saying is looking at it more systemically, right? The entire collection of data, and securing it, but also uses of that data and sort additional intelligence and things you can mine from it.

    It’s interesting—so much, as we continue to move more and more into the digital economy, digital world for how we operate, all of those digital activities generate their own data, too. So, now, we’re adding that to the fabric of the data of, you know, we have a lot more usage information, we have a lot more telemetry that we never had. You know, it seems to be expanding exponentially. So, our ability to even just fathom what’s there and how it’s—what uses it might have and how it might be correlated in new ways sort of boggles my mind. [Laughter]

    Bennatan: Yeah, yeah. And, you know, I mean, it used to be this—one of the things people used to talk about when they started building big data platforms was that, you know, until recently, we just, we couldn’t use our data. We just threw 97% of our data away, and now we don’t wanna throw it away, but you’re right, it’s a beast that feeds itself.

    Ashley: Mm-hmm.

    Bennatan: But yeah, I think it’s, I think looking at the risk profile of the entire thing and not cutting into separate projects, which then have no tie to each other, right? I mean, if you want to reduce the risk, you asked about prioritization. Okay, prioritization needs to drive everything, right? Needs to drive reducing service area, needs to drive access control policies, needs to drive audit. If you start separating each one of them, not only is it not very effective, but it means you’re working 10 times harder, because you need to do this many, many, many times.

    So, this notion of a single kind of data security platform which kind of can have this internal feedback loop and use whatever effort you’re doing, it doesn’t matter if your effort is driven by compliance or security or privacy, whatever investment you make needs to build into this platform, not do itself over the next time you do anything. Otherwise, we’re just wasting our time. We’ll never get done. Because you said the data’s growing exponentially—if we’re chasing, if we’re not leveraging what we’re doing for one purpose when we wanna do the next purpose, we’re gonna lose. It’s gotta be a single platform.

    Ashley: Well, and to your point, it seems that once you sort of make that shift, right, to that platform view of data, now you can apply that to how you look at the data across all sources, all uses, all former kind of vertical siloed—you know, you may still want to look at it that way, but it’s not like, “Okay, now we’ve figured it out for compliance, but we’ve gotta go start over to do it for something else for operational process or whatever.”

    Bennatan: Exactly.

    Ashley: No, it’s there, you kinda take that—

    Bennatan: Exactly.

    Ashley: – those same tools and look at the data, analyze it. Now you’ve got that capability to do that for lots of things.

    Bennatan: Yeah, it’s exactly—it’s exactly right. I mean, you know, it’s like, in the business world, there was always this notion of a customer 360 where, you know, what’s the point that I have one system for quotes and one system for support and one system for my policy and I never know what’s going on, and I can’t upsell, and I can’t cross sell. It’s the same thing in security, okay?

    There’s this notion of data 360, data security 360 where, if it’s there, you know, then prioritization becomes easier, right? If you can check your configs and your vulnerabilities, okay, and you get this huge list—what are you gonna do? But if you know that, of this huge list, your consumer data is here and that, you know, the crown jewels are here—great, you don’t have to boil the ocean.

    Ashley: Mm-hmm.

    Bennatan: And if, at the same time, you can bring in and you can check your entitlements and you can say, “Well, you know, I have this vulnerability, and it is important data, but I did a really good job at narrowing it down and access to it is only by these individuals and access is Kerberized and—I don’t know, and maybe I also regulate the policy very tightly—these are all related, okay? So, if you have that single platform, you’re in much better shape than…you know, it’s like, I’m trying to think of a metaphor of, you know, when you have a single viewpoint, that viewpoint may be wrong. When you have—it’s kind of like, you know, these days, this discussion about whether news means anything any more, because it’s so tailored to what you wanna hear.

    Ashley: Mm-hmm.

    Bennatan: But it’s kind of like somebody forcing you to go and watch Fox and CNN and NPR and—you must watch all of these before you make a decision. It’s the same way. We can’t reduce risk by just looking at one thing at a time.

    Ashley: Yeah, we certainly have our own selection bias and data as we do our news programming as well, right? [Laughter]

    Bennatan: Yes, exactly.

    Ashley: Well, this has been a lot of fun talking with you. I just have a sense 2021 is already off to a good start with vaccines and the COVID situation. Hopefully—

    Bennatan: Hopefully.

    Ashley: – you know, we’ll round that hump and folks can really figure out new ways of collaborating with each other without worrying about COVID. Maybe that day’s down the path not too far, but we hope, anyway.

    Bennatan: Yes.

    Ashley: So, it’s been fascinating talking with you. So, we didn’t talk about, you know, go into product stuff, it wasn’t that conversation, but tell us a little bit about where folks can find out more about Imperva.

    Bennatan: So, Imperva.com, we are—you know, if we’re talking about data security, then there’s a whole section there, and you’ll see that we’re investing a lot in, you know, things that we believe 2021 and our customers are implementing. So, a lot of kind of complete security, complete security, whether it’s for compliance, security, privacy—a lot of effort in privacy, a lot of effort around data lakes, everything around cloud. Any cloud that you can think of or any data service, any data-centric workload on the cloud is something that we’ve worked very hard with the cloud vendors to provide support for. And yeah, I think 2021 is gonna be an exciting year because of this modernization that everybody’s embarking on.

    And my hope and what we’re trying to do with Imperva is that the path of modernization for the applications and for functionality also brings with it modernization of security, updated security. That’s really what we’re working on.

    Ashley: I would definitely suggest folks check you out. In thinking about our conversation before of the response to regulation and policies and things like that of looking at what other leaders do, Imperva works with some very impressive companies who are solving the data challenge from a platform standpoint. So, there’s a lot of good reasons to check out Imperva, because there’s a lot of problems you’re solving on the advance that could help a lot of organizations, so I hope people will do that.

    Bennatan: Yeah. Well, thanks, Mitch. Always great to talk.

    Ashley: You bet. Good to talk with you, Ron, and thanks, everybody, for listening in. It’s been a great conversation, and I wish all of you a great 2021 as well.

  • 3 Ways Traceability Boosts Decision-Making, Accountability

    3 Ways Traceability Boosts Decision-Making, Accountability

    Traceability can be a key tool to allow for a streamlined process of complex decision-making

    New software is being developed at an incredible pace to help make our lives easier. This doesn’t change the fact that humans are still held accountable for product development decisions, whether these are made with or without advanced analysis tools. To make informed choices, product development professionals need tools that allow them to see comprehensible information in real-time as change is happening, both within the team’s structure and throughout the system in which their product exists.

    Modern traceability makes it possible to both manage and respond to change in a systematic, auditable and confidence-enhancing way. Below, we will discuss three ways traceability has evolved to support key decision-makers in a number of industries.

    Modern traceability captures when you make a decision

    Decisions often have varying levels of durability. Sometimes, when you make a decision, you know then and there it’s final. Other times, you make what seems to be a minor choice and you end up dealing with the repercussions for years to come. With this level of uncertainty, it is essential to have mechanisms that allow you to see when decisions are made. As I discussed in a previous article, “5 Ways Traceability is Changing to Bolster the Remote Workforce,” this process can be compared to a map. By leading a team through every step of their processes, modern traceability helps product developers reach their goals without any surprises.

    Often, products are expected to be maintained for years. This is significantly more challenging when you can’t properly track where a ruling originated or a change was made. While the team may move quickly in the development process, the record should always live on to provide future context where it’s needed.

    Modern traceability provides people the context of what they’re working on as they go, not after the fact

    Rather than rely on sharing often lengthy and disparate documents or running time-consuming general meetings, traceability allows teams to streamline their collaboration. Mapping out work items, including owners and contributors, gives people a reason to care and to trace those items carefully. It helps everyone know why they’re there, what they are discussing and how to address it.

    Many smaller companies are fortunate to get by using Word documents and other legacy tools for their traceability measures. However, as these companies grow, so do the complexities. That’s why traceability has been evolving to account for the multi-dimensional nature of requirement, test and risk management. For a company that is seeing major growth to be truly successful, all related variables must work together continuously, at scale and across teams. Legacy tools simply do not provide the agile capabilities that modern traceability does.

    Traceability captures and tracks past decisions and allows users to access them

    Traceability is all about relationships. Each product in development has its own particular set of customers, stakeholders and internal team members associated with it. Therefore, traceability is only possible if these individuals can be accurately connected to the items for which they are responsible.

    Knowing who made a decision and what information they accessed is equally as important as the information itself. If you can’t quickly piece that together, your traceability is incomplete. The responsible thing to do is to ease the process by keeping useful records. It doesn’t need to be forced behavior if it’s captured along the way as a byproduct of doing your job.

    Overall, accountability is incomplete and past decisions can’t easily be seen, learned from or built upon without robust, modern traceability tools. It’s much harder to legitimately hold someone accountable when they’re working in the dark. However, when done correctly, traceability can be used as a key tool to support genuine liability and allow for a streamlined process of complex decision-making.

  • What Developers Must Know About Threat Modeling

    What Developers Must Know About Threat Modeling

    Threat modeling is a process that far few developers seem to pursue, but it is a process that helps you and your team to model all potential threats to your application. Essentially, threat modeling is your thinking through all of the potential threats against an application. Doing so is virtually as easy as putting together a list of threats in a structured manner that lets you assess any perceived risks, allowing you to formulate how you are going to respond to the threats.

    Ultimately, through threat modeling, you are optimizing network security by identifying objectives and vulnerabilities and creating measures to prevent the effects of threats to the system. Through this definition, anything described as a threat has the potential to be malicious to your organization and data systems; for example, incidental occurrences like the failure of a storage device–which can compromise the integrity of the entire enterprise.

    The reasons for threat monitoring may be pretty obvious, but any lack of progression here is quite common.

    Threats are one of the significant factors that led companies to spend $89.1 billion on enterprise security solutions. Gartner predicts threats will reach $96.3 billion by the end of 2018. According to Raytheon’s 2018 Study on Global Megatrends in Cybersecurity, 36% of senior IT and cyber professionals identified malicious or criminal insiders as a top cyber threat. Even with that knowledge, many organizations lack insider threat policies and policy enforcement tools, and they struggle to align security and IT responsibilities to tackle the threat effectively.

    Threat monitoring allows you the ability to determine which threats might exist for your application. Knowledge is power, and it’s always better to know beforehand what dangers might await you. Understanding these threats lets you decide whether you will accept the risk.

    For a threat to exist, there must be a combination of the following where the combined likelihood and impact are significant enough in which to do something. A framework for understanding threat modeling, includes: asking what you are working on, what might go wrong and what to do about it, as well as if a job is well done.

    According to the Open Web Application Security Project (OWASP), threat modeling is a process that lets you continually refine your processes based on what you have done so far: “Starting with all possible vulnerabilities is usually pointless, as most of them are not attackable by the threat agents, protected by a safeguard, or do not lead to a consequence. Therefore, it’s generally best to start with the factors that make a lot of difference.”

    Those steps include assessment scope, identity threat agents, existing countermeasures, identifying vulnerabilities, prioritizing identified risks and identifying countermeasures to reduce the threat.

    In the assessment scope, you’ve got to understand the price of what’s at stake. Identifying tangible assets, such as databases of information or sensitive files, is usually straightforward, and realizes the capabilities provided by the application.

    Next, identify possible threats or attacks. A crucial part of the threat model is characterizing different groups of people who might be able to attack your application–this may include insiders and outsiders, performing both inadvertent mistakes and malicious attacks. During this phase of development, consider existing countermeasures that allow you to determine what possible exploitable vulnerabilities exist that must be addressed. Through your search, look for weaknesses and connect any attacks you’ve identified to the negative consequences you’ve identified.

    When identified, risk management can be prioritized. For each threat, determine possible outcomes and the impact of those to understand how to mitigate these issues. Next, look for ways to reduce any future risks.

    While many of the threats might appear to be security related, many others have more natural explanations. Threat assessments can include power outages or even a flooded server room. These and other factors can lead to severe threats to your organization.

    When to Model the Threat?

    Threat modeling is often best at the beginning of a project, but it’s better to conduct a threat modeling project halfway through a project or even at the end than not at all. Threat modeling at the end of a project can have benefits, such as understanding the architecture and how data flows through it. However, threat monitoring at the end of a project can lead to finding more work may be required to fix poor design decisions not caught at the beginning.

    For those entering into threat modeling, conduct your first session on an existing project, letting you experiment with a threat modeling session so that you can familiarize yourself with everything required. This way, you’ll be better prepared to analyze all assets and flow of data to assess the risks. Once the process is pounded out, you’ll have a better chance of succeeding in your threat modeling of a new project. You’ll also be able to better prepare for threats that may exist in the design phase of the project. From here, over time, you’ll begin to take into account threats during the initial design of a new feature.

    Approaching the Threat Model

    Each method of approach depends on the organization and its goals. Large organizations usually have previously established processes for threat modeling. Smaller organizations new to threat modeling can begin by hiring in experience to initiate the task or seeking outside support from experts or those who can advise the program.

    Next, you need to understand who the users are within the system–regular users, administrators, outsourced contractors and perhaps hackers with apps or other tools looking for vulnerabilities within your network. There are also other actors, including disgruntled former employees.

    Defining the user actors is important since missing a group can mean you might be missing an entire category of threats. Also, consider the various types of hackers or groups of hackers in your models.

    Data and Information Flows

    At this point in the threat modeling process, track each of the various data flows running through the system. For each of these, you need to know where the data goes. What does it interact with or encounter along the way? Then look to identify where data can leak or where it might be exposed. More data components create more opportunities for a hacker to gain access to the information.

    Individual data means the information flows differently based on the architecture and the specific situation. One example might include a request from a user’s browser where the cookie is sent through and interacts multiple components as it does.

    For each data flow, search opportunities for any actors to gain hold of valuable information. If anything makes you frown, step back through the process and move that threat through until you can mitigate the frowning moment.

    Threat List Complete

    When the threat list is observed and complete, prioritize the list from very unlikely to improbable to not likely. No matter the probability of the risk, work through the risk as a real possibility. Do so to consider the real impact of the threat and what it may mean to the organization. Is the company going to crash and burn completely? Will every bit of data get pulled into a ransom situation? Place a number or priority of the impact, such as low, medium and high.

    When you have your risk list, manage the risks by:

    1. Accepting: If the risk is quite low, accept the potential impact. It’s also possible you’ll find the potential negative user impact is more important. You can also reassess later.
    2. Transferring: Perhaps another team is responsible for managing a particular risk. If that team can pick up the defense easily, outsource it.
    3. Avoiding: Don’t do this. If you must, consider complete structural changes to your data flows to avoid altogether avoiding risk. This might mean architectural changes are required or killing a particular feature altogether so as not to avoid danger.
    4. Reducing: Take actions to lower the risk by lowering the likelihood or impact of the risk. You may need to take multiple steps to reduce the threat. No matter the action, effort is required to reduce the risk.

    After threat modeling is complete, don’t stop. Keep working because threats and actors change. List all potential issues or risks that must be addressed and work them into your plan.

    Finally, remember you should be careful with whom you share your threat modeling plan. You never know where that information might end up otherwise, or who might be a threat to your organization and its data.

    One last note: The final result and usefulness of threat modeling depend almost entirely on the parameters established. Defining the values for the probability of a threat and impact may be subjective, but let your experience, input from colleagues and experts, and your gut guide you.

    — Jeroen Boks

  • Common Pitfalls of Software Development and Tips to Avoid Them

    Common Pitfalls of Software Development and Tips to Avoid Them

    In business, no one wants to plan on failure. However, when it comes to software development, failure is more common than most managers want to admit. In particular, many managers and executives fear large software-based projects are especially likely to fail due to the complex nature of these projects and the nuanced reality of the deliverables.

    While there is no doubt a software development plan is complex, there is no reason to be so readily consigned to failure. In fact, it might be argued that software is so important to your operations that failure should be viewed as unacceptable. However, this aggressive approach in theory needs to be backed up with proper execution in practice. That is why you need to know the common pitfalls that befall most software projects. This is the only way to make sure your company avoids them.

    Vague Project Requirements

    One reason so many projects fall short of the mark is that these projects fail to define the mark adequately. Your software development project cannot succeed until you know what you really want it to do. This means your project specifications need to be clear from the very start. Your goals should be defined first, and then these goals should be consistently reiterated to team members throughout the process. This includes the scalability of the project. The development team needs to know what features should be included in order to produce a final software solution that actually meets your company’s needs.

    This is all part of developing a versatile software development plan. A good software development plan will anchor your project from start to finish. A poor one will inevitably leave you vulnerable to failure.

    Unrealistic Timeline

    The timeline matters to the company, which is why some companies set aggressive timelines as part of their software development plan. However, while these timelines sound good in planning sessions, they may not make much sense in the daily development process. It is pivotal to think carefully about a timeline in order to account for development, testing and more. All parties should be consulted in the development of the timeline. This includes high level executives, project management and developers. This varied input should allow the project to accommodate the needs of management alongside the needs of developers. This is a form of risk management because an insufficient timeline will lead developers to cut corners, leading to a lackluster result.

    Unbalanced Staffing Commitments

    As you define your software requirements, you will need to think about the team members who will bring your plan to fruition. If you do not assign enough people to the project, production will fall behind. However, if you put too many people on the project, things can start to get messy. Overstaffing a project can easily lead to miscommunication, and it is harder to keep a large team of people unified. This can also lead to redundancy and a lack of consistency if too many duties are spread out. For these reasons, it is important to assess your staffing situation correctly from the start. Be sure to include your project management team in the final staffing decision.

    Insufficient Testing Procedures

    In all your planning, it can be easy to neglect testing. The reality is testing should be a critical part of your plan, accounting for a significant amount of your timeline and resources. Testing is important because it allows the development team to iron out any problems with the software. All software will have bugs in its early versions, and these bugs can be caught and fixed with sufficient testing. Testing is the only way to make sure your software works the way it needs to work. If you implement deliverables that do not perform, then your workers will be flummoxed, your consumers will be disappointed and your security could be at risk. Therefore, allot plenty of time for testing throughout the entire development plan, allowing for each component to be tested prior to going live.

    Poor Hands-On Leadership

    If you really want to make sure your project goes well, then make sure you have good people in place to lead it. Your project management team is absolutely critical to successful software development. A good project manager will internalize all parts of your plan. This includes the budget, the timeline, the goals and the staff. Your project managers need to facilitate communication, manage schedules and oversee adjustments. This key leadership role is your software development plan in action. Make sure you hire the person with the right skills and the right experience. Then, make sure that person knows exactly what your goals are to achieve success.

    These pitfalls are common for a reason. However, with a little foresight, it is possible to keep your project and your company from disaster.

    — Shane Zilinskas

  • Continuous Testing and Business Assurance

    Continuous Testing and Business Assurance

    As development moves ever faster, continuous testing can help further reduce the risk of introducing errors

    In IT circles, “risk management” implies information security. But in the business as a whole, risk management is a function that spans the organization. The risk that an application will negatively impact corporate image, sales or employee morale is very real in the age of automating everything.

    Once properly identified, these types of risks can be mitigated with continuous testing processes. The ability to set up a test to prove the login system works as expected keeps users able to get to the application.

    Increasing use of agile and DevOps offers the opportunity to receive rapid feedback. Among other things, that includes business (as opposed to InfoSec) risk management. Requirements from the business side can clearly delineate items that create risk for the business unit and the requirements to reach desired outcomes. Continuous testing can turn those requirements into tests that validate the application is not contributing to business risks.

    After all, there are enough risks in the business environment: competition, suppliers, coordination of marketing, legal, etc. Making application development less of an issue is good news for business owners and IT alike.

    By translating business risk management requirements into automated tests early in the development process, stability and risk aversion are built into the application from (or nearly from) inception. This offers stability and provable correctness in the application development cycle.

    As the pace of development continues to accelerate, there is a risk of negatively impacting the user experience. Whether that negative impact be through failures of critical parts of the system or degradation of performance, it harms the application and the business it supports. Continuous testing can help alleviate fears by testing for these scenarios and pointing developers at fixing them early.

    Test automation tools are becoming more prevalent, and the next step is to include business requirements designed to mitigate business risks at every step in the process. It is simple to say and test “valid users must be able to log in,” but as development progresses, if the login prompt takes more than 10 seconds to return, that adds the “in a timely manner” business requirement that is then refined by IT to a number, and a new test is run. Only by having the inputs from the business at each stage can such refinements be identified and implemented.

    Interested in this topic? Check out the ebook here to hear from experts on balancing speed of development with risks to the business.

    And consider it. The purpose of any given piece of software is to serve the business. Speed that introduces unwarranted risk to the business cycle is not the best answer. Continuous testing, and attendant business owner involvement, can mitigate those risks.

    — Don Macvittie

  • How to lower risk in agile development

    How to lower risk in agile development

    The increasing complexity of application development and subsequent rise of Agile development is changing the risk appetite in many software development organizations. Unless you’ve got an application which is highly regulated or mission-critical, it’s rarely feasible or sensible to manage Quality Assurance within the zero-bug environment often associated to Waterfall. Software development teams can become handcuffed by the lack of flexibility and struggle to maintain a focus on delivering business value. Agile methodologies paired with DevOps emphasize speed, rapid iteration and a “fix as you go” mentality over driving toward a perfect product out of the gates. So how can we lower risk in agile development?

    There are other contributing factors to the growth in software risk, notably the continuing adoption of cloud computing. Given the appealing economics and flexibility for updating and repairing code in the cloud, many teams will choose to host even the most high-risk data on the cloud. Conversely, teams must focus even more attention on security, as the cloud exposes more data outside of the company’s network.

    Software interdependencies are another risk; many business processes today rely upon the use of outside services from APIs to OAuth authentication. Teams must be on top of changes in these external systems to ensure that critical functionality can still operate. This is especially true in a mobile context, where even the operating system and hardware components are changing at a rapid pace.

    There doesn’t have to be a trade-off between speed and quality. It takes a change in mindset and processes, however: managing software risk in the age of Agile and cloud is a whole new game. Here are a few things to consider:

    1. Balance risk with business needs: A shining reason behind Agile’s popularity is the unceasing demand for speed and business alignment. Software and IT organizations have realized that in order for their employers to be competitive, they must operate in ways that are highly business-responsive and adaptive. Agile also helps organizations address the complexity of software development today, given the impact of mobile devices, the proliferation of new languages and tools for Web apps, growth in cloud-based computing and the overall importance of digital processes to a company’s success. QA teams need a more educated and informed approach to testing. That means taking on a measured approach to risk, wherein risk management tasks are implemented with business priorities in mind rather than as a one-size-fits-all strategy.
    1. Risk-based testing: In order to take on more risk as part of Agile and DevOps thinking, there must be proper checks and balances integrated within the testing process. Instead of testing every feature and function, and shifting timelines, prioritize testing and quality management measures to fit business priorities. Risk-based testing commonly assigns a risk rating score for individual tests, which gives developers and QA an idea of the level of risk involved in delivering the code covered by that test if the test is skipped. As a result, the product team might spend more time testing versions of the application for devices which comprise the most important or largest sector of the customer base. However, common device types and operating systems are not the only variables that can factor into risk scores. For example, if one particularly large customer relies on a key feature or function, that should mandate additional testing around that area of the application. By linking business drivers to development and testing, organizations can still deliver quickly yet with the assurance of superior results in the areas that matter most to revenues and customer satisfaction. Ongoing testing of high priority application features also results in the avoidance of costly, wholesale changes down the road.
    1. Integrate development and testing: As mentioned earlier, integration between development and testing is critical for many projects, yet it is frequently overlooked when managing Agile teams. To maximize success, there needs to be a deeper understanding between coders and testers on potential ripple effects of introducing new features as they are planned. This can occur during the everyday processes of Agile collaboration and sprint planning. Testers should know early on which are the top risk areas affected by a piece of new development; testers and developers both should incorporate development best practices which focus on understanding and planning for interdependencies, such as designing code that limits the downstream impact of integrations.
    1. Best of Breed tools: The market for tools has expanded vastly along with the onset of cloud, mobile, social and big data technologies and the DevOps and Agile movements. The average IT shop is using dozens of tools for application lifecycle management (ALM), build, automation, project management, change management and testing. The newer tools, designed for Agile and Web development, allow for rapid iteration yet still provide controls and collaboration features to minimize risk. Beyond functionality, look for tools that will integrate with your existing toolsets. This will allow for faster, real-time visibility on application deliverables, new features and any quality issues that have been discovered.

    Software development is more complicated today than ever. The good news is, it’s much less expensive, faster and easier to make a change in the code compared with even a few years ago. Incorporating some risk into a product is good, because it means that innovation and time-to-market are top of mind. However, introducing too much risk in high-priority customer areas or critical periods in a company’s growth can sink a business. Understanding the difference is what can allow you to keep both your customers and executives happy, with a brisk yet manageable pace of innovation.

    About the Author/Kevin Dunne

    kevinKevin Dunne is the Director of Product Strategy at QASymphony, ensuring their continued commitment to innovation and delivering tools to create better software. With a deep interest in the emerging trends in software development and testing, Kevin is dedicated to collaborating with thought leaders in this space.

    Kevin comes to QASymphony from Deloitte, where he managed testing on large government and Fortune 500 engagements delivering ERP implementations and custom software development. As one of the first employees at QASymphony, Kevin has seen many facets of the business working in sales, customer support, marketing, and product management.

    Kevin holds a Bachelor of Science degree from Vanderbilt University. Connect with Kevin on twitter.