Security Testing

Transcript

This week, we are joined by Dan Billing, a software security penetration test specialist at New Voice Media in the U.K.. Dan describes his path from everyday software tester to security expert, and the variety of approaches and methods, as well as tools, that come into play if you want to take a crack at being a software tester with a specialty towards security testing.

Also, can thirty years of fMRI results really be invalid, and what are you doing to take on the “30 Days of Software Testing” challenge?

Panelists:

References:

Transcript:

MATTHEW HEUSSER: Hello, everybody. Welcome to The Testing Show. As always, I’m your host, Matt Heusser. This week, we are joined by Dan Billing, a software security penetration test specialist at New Voice Media. Did I get that right, Dan?

DAN BILLING: My actual job is senior test engineer, but I lead the security testing at this business, yes.

MATTHEW HEUSSER: I got to meet Dan, your presenting in Estonia a couple of years ago.

DAN BILLING: That’s right.

MATTHEW HEUSSER: And then, we ran into each other at TestBash. Dan’s based in the UK. I’m going to get this wrong. Is it near Cambridge?

DAN BILLING: Actually, I live in Somerset, a place called Frome. It’s near Bath, in the Southwest of England, but my office is in Basingstoke, which is in the South in Hampshire. Cambridge is way over in the East, and Dan Ashby lives there. So, lots of testers live that way.

MATTHEW HEUSSER: I was going to go for a coincidence, because we’re joined by a couple of people from our usual cast today. Perze Ababa is joining us from Cambridge, Maryland. So, there was at least one Cambridge in there. Welcome back, Perze.

PERZE ABABA: Hi, good morning, everyone.

MATTHEW HEUSSER: And, Justin Rohrman, of course, is from Nashville, Tennessee.

JUSTIN ROHRMAN: Good morning.

MATTHEW HEUSSER: This week, we are recording without Michael Larsen. He is out in Philmont, New Mexico, hiking in the woods with his Boy Scout Troop. We may have to do a few of these episodes. He’s going to be gone a couple of weeks.

DAN BILLING: He’s a scout leader, did you say?

MATTHEW HEUSSER: Yep.

DAN BILLING: A coincidence, so am I.

MATTHEW HEUSSER: Not to tangent too much, but I was a Star Scout, and I believe Justin was Life.

JUSTIN ROHRMAN: That’s right. I just missed Eagle by “the project.”

MATTHEW HEUSSER: Wow. You had all the badges and everything? Man, that’s wild.

JUSTIN ROHRMAN: I had the project in progress too. I just couldn’t put it all together.

MATTHEW HEUSSER: Wow, that’s rough.

JUSTIN ROHRMAN: Yeah, [LAUGHTER], it is.

DAN BILLING: We do it slightly differently here. But yeah, that’s for another podcast. [LAUGHTER].

MATTHEW HEUSSER: Well, let’s get started with some of the News of The Day. The first thing I wanted to talk about was the 30 Days of Testing Challenge, put out by Ministry of Testing, which is Rosie Sherry’s umbrella organization that also runs TestBash, and we will have a link to it in the show notes. Every day there’s something new. You can buy a book. You can listen to a podcast. You can take a picture of your office and put it up on media. I think it’s just fantastic to get people to seriously commit to their profession for one month. It’s not asking too much, and really, Ministry of Testing is really UK, Europe more than the U.S., or at least it started that way. They have conferences now in the U.S. too. So, Dan, tell us a little bit about 30 Days of Testing. I think you’re a little more involved with it than I am.

DAN BILLING: I’ve been following the news over Twitter. [LAUGHTER]. Myself particularly, so far, I’ve managed to complete at least two or three. We’re into day 12, I think, now. Last week, it was, “Create a mind map of some testing” you were doing, or as you say, “Listen to a podcast.” I listen to a security podcast. It’s called the, Silver Bullet Podcast. Oh, I read a new book. So I read, Dear Evil Tester by Alan Richardson, which is basically a set of anecdotes and answers to questions he’s received over social media or e-mail or at conferences, and he’s kind of brought those together into a semi-humorous journey through his experiences in testing and the answers he’s given to those questions. It’s quite an insightful book and exciting read. It’s quite a slim read, so it’s not super-detailed. But, the book is very funny. But, the real thing that I’ve noticed with the 30 Days of Testing Challenge is that it really captures the imagination of testers and testing around the world. So, I’m really excited by that. I’ve been to every TestBash for the last four years and applied to go to both of the American TestBashes as a speaker but failed on both occasions, sadly. I spoke at the last TestBash. One of the things I’m really impressed with, with the Ministry of Testing, is its ability to reach out to testers, whether you’re new to testing or whether you’re an old hand, a veteran. I would probably consider myself a veteran now, because I’ve been doing this for like 15 years, and there’s still a lot to learn even the length of time I’ve been doing testing. Challenges like this really engage. It really gets people excited.

MATTHEW HEUSSER: Yeah. The book that I read is called, The Obstacle is the Way, and it is a popular-easy read, fun read, summary of stoicism—the Ancient Greek and later Roman Philosophy. So, it’s generally associated with just being tough and, “Whatever doesn’t kill me makes me stronger,” but the premise of The Obstacle is the Way is actually, “Whatever you’re struggling with right now, you can find ways to get that to inspire you to do better, to sort of slingshot you forward.” The second major news item is this MRI scanning issue, and I thought maybe Justin could talk about that for a minute.

JUSTIN ROHRMAN: So, an article came out in the Wired (UK Version), fMRI software and software use. When you go to a doctor and you lay down on this bed and they slide you inside of a machine and rotate this big magnet around your head that has three different kinds of software in MRI machines. Each of these was found to have a false positive rate of up to 70%, meaning that maybe it showed some kind of attribute for cancer or some kind of brain abnormality, and it was wrong 70% of the time when it did that. Aside from, [LAUGHTER], giving people false diagnoses, the software bug is invalidating about 15 years of medical research.

PERZE ABABA: So, if you look at this from a regulation perspective, there’s multiple classes of medical devices. So, the class III is the highest one, where there’s more rigorous validation required. It’s not just the hardware but the software that comes with it as well. So, I found out that there are some parts within an MRI device where some of it are actually classified as class III and some it are marked as class II, and then all of them has to go through this—what we call—510(k) process, which is your premarket approvals. It’s like our staging server, so to speak. [LAUGHTER]. So, the biggest question that I really have here is that, supposedly this should have went through all of that. Since 1976, when this was classified as a class III, there should have been very specific quality gates that, whoever wrote this algorithm, it should have gone through and they were given the burden of proof to not just only prove that it works according to how it was designed but what the false positives are going to be. That’s the biggest question that I have at this point, “How did it take this X number of years before we realized,” and now we’ve affected—what?—40,000 or so research papers, and not just that, but you’re looking at 70% more false positives. I mean, can you imagine? [LAUGHTER].

JUSTIN ROHRMAN: So, I guess, to get real clear about the false positive real quick, let’s say that there were two patients—one had Parkinson’s disease and one did not have it—so you send both of them through the MRI machine. The MRI machine might end up saying that both of them are “showing this attribute of people that have Parkinson’s disease.” According to the scan, you never know which is correct.

MATTHEW HEUSSER: So, it seems to me that they tested the software to see if it matched the algorithm, but didn’t actually go back and test to see if that matched real users for both problematic users and a control group.

JUSTIN ROHRMAN: Right. Only for the ways that it’s supposed to work, instead of the ways it might fail.

MATTHEW HEUSSER: Maybe we should segue here and talk about security testing, which is why we have Dan on, right?

DAN BILLING: Yeah.

MATTHEW HEUSSER: So, Dan, I believe you started—? I’m really interested in these kind of lateral shifts. Tester-to-business analyst, pretty easy. Tester-to-developer, maybe you’ve got to go take some CS Courses, but it’s relatively straightforward. Security testing specifically seems like a “black art” that is not talked about much, and the difference between, “I’m an amateur, and I know how to do the attacks,” and “I’m a professional and I can certify your E‑commerce application,” there’s a big gap there.

DAN BILLING: We need a little bit of history here. So, about 2008 or 2009, I was working on applications that we’re going to be sold to our police services in the UK. You know, they were buying criminal investigation software or anything to do with managing payment of fines and issuing tickets. Speeding fines for example, if you got caught speeding either by an officer in person or via a camera. I was working on those kinds of systems for about two‑or‑three years, and one of the things that came up in the requirements documents—and we had lots of traditional requirements documents—was the nonfunctional requirements and security was generally listed there. When I sort of questioned, “Why aren’t we doing the security testing or what security testing are we going to do,” that was generally put to one side saying, “Okay. We’re not going to touch that, because one, we don’t have the skills in-house, and two, we don’t have the time to do it right now.” So, it would generally be left to the last minute, or it would be done by an external company. That’s generally been the pattern for a lot of companies for many, many years that they would bring in an external resource to assist with that. So a consultancy that would help you do it. Security, I feel, is doing something internal to your business and penetration is essentially someone trying to get through the doors from the outside in. I’m generally working from the inside. So, around 2010, I went freelance for a few days, and then I ended up here at New Voice Media. I’ve basically spent the last three years, give or take, training myself in various security testing techniques, learning about the theory of security, through attending conferences and speaking to people and reading documentation, looking at the OWASP material that’s out there. So, I don’t know whether you guys are aware, but OWASP is the Open Web Application Security Project. They have a lot of free resources for learning, to help you train yourself to do this kind of thing, and also lots of frameworks and tools to help you as well. So, that’s kind of where I was starting from, using what was out there, available for free or very little money indeed, taking one-or-two classes as well, which would help me. One of the best resources I’ve ever hooked onto is the video training courses that are available on the new training site Pluralsight, which are crafted by the security expert, Troy Hunt. So, I follow his blog quite carefully and learn a lot from him, from his videos and his training.

JUSTIN ROHRMAN: So, the security work is really a black box and we have no clue what it looks like. What is the day in the life of a security tester?

DAN BILLING: So, for me, at the moment, I consult into all the other feature teams in my organization. So, they are building new products, new services, for our customers. Before, I was actually in one of the feature teams, where I was doing a lot of security work. But now, a newly-formed security team, that means I come along and I’m invited to work alongside the other developers and testers, show them good ways of working with security tools and security itself, techniques that they might want to use for their particular pieces of work, or if they’re building new features and forms, or other functionality, then I would support them in that regard. I would spend time researching particular issues. You know, if we found a particular problem, I would look into that for them and share the knowledge with them. I also do training and facilitate learning, both from a paired point-of-view with other testers but also with large groups and workshops across the entire business. So, a part of my role is, not just the testing side of things, but also mentoring and education across the dev team and also in other areas of New Voice Media. Security awareness generally as well as just the technical security.

MATTHEW HEUSSER: One thing that I think is cool, that is happening with the Agile Movement, is that we’re taking these ancillary roles—DBA and operations—and we’re bringing them into the team, hiring. Part of my interview process is, when people do exercises and they say they’re “done” and they haven’t even mentioned security.

DAN BILLING: Hmm.

MATTHEW HEUSSER: It’s okay to say, “Do you want me to do security testing? I don’t know, I haven’t done the research.” At least have that conversation.

DAN BILLING: I’d agree with that, Matt. I mean, you may not have the knowledge or skills, yet but it’s bringing that expectation that you have to think beyond the square that your projects sits inside, and one of those things is security. I think that there’s a lot we can do. If we can knock off the top three, very quickly, and say, “Hey, we’ve tested for that. We’ve tested for SQL injection. We’ve tested for cross-node scripting. We’ve tested for broken authentication and session management.” If you can do those top three that gives you, immediately, a level of comfort about your software. We aren’t just testers. We are also project managers. We’re also analysts. We’ve become much more operationally aware, understanding architecture and things like that. Security is very much a part of that now. Something that we’re looking to do in New Voice Media is, have security as part of DevOps or part of Dev, embedded heavily inside it, become second nature.

MATTHEW HEUSSER: I think that’s great. Now, there are other things that we can do when it comes to Pen Testing. There are scanners you can run against the website that comes back with “the version of Linux” it is on “the version of WordPress” it is on, all of the little things, and then you can Google, “Hey, WordPress-12345.72, what are the security holes?”

DAN BILLING: There are lots of ways you can do that, Matt. You’re quite right. So, for example, one of the tools I use quite heavily is one of the OWASP tools called Zed Attack Proxy. Like, a lot of proxy tools, like Fiddler, it sits between the browser and the server and it observes all the requests that are going through the browser, but then it will allow you to spider that website or the application that you’re testing to find new pages. It will allow you to do an active or passive scan against that application, and then it will allow you to do more detailed stuff like testing for something called cross-site request forgery. It has a whole bunch of its own built-in heuristics. One of the great things about it is that you can include it in your CI. It has a lot of integrations with things like Jenkins and you can script it up in Python or Ruby or whatever flavor of code you enjoy. I’ve been learning Python and Java myself recently. So, that’s been very helpful. There are ways you can incorporate a lot of these tools in. You mentioned port scanning. There’s one called Nmap. There’s a whole bunch of others. If you watched any of the Bond Movies or the Matrix, and they have a green screen on it, coming up with lots of strings of data, that’s generally Nmap they’ve been using.

MATTHEW HEUSSER: Did not know that.

DAN BILLING: Yeah.

MATTHEW HEUSSER: That’s cool.

DAN BILLING: Yeah. They generally just take a screenshot of Nmap running in the background, because it looks kind of cool. It looks like code. It’s just a port scanner, and it looks kind of awesome. I think it was definitely in one of the Bond Movies and definitely in the Matrix. So, [LAUGHTER], I don’t know whether it’s turned up anywhere else, but yes, [LAUGHTER], because is, of course, all about security. One of the things I would like to, sort of, counter would be the “dark-art” thing, Matt. What I want to try and do is enable testers to be able to encounter this stuff into their work, day-to-day. I do that internally in my business. I’ve written a plugin for a so-called bug magnet. You guys must know Gojko Adzic. He did Specification by example, that book, but he also wrote a tool called Bug Magnet. You can customize Bug Magnet. You just incorporate a .json file into Bug Magnet, and you can customize it. It’s got some cross-site scripting filter evasion techniques built into it, rather than the standard techniques that are supplied by the tool. So, I can do that, and I can add SQL injection to it. So, I can leave the tool to go away and do something and then it’ll alert me that, if there’s a problem, come back. I’ve also got some simple ways of incorporating the “nasties” into my testing every day. One of the things I have to be aware of though is that security isn’t everything. You have to have it in balance with all the other things we’ve talked about—performance, usability, and accessibility. There’s no point in having an application that so secure that no one can log into it and use it. You need to still make it usable and accessible to people as well as protecting their data and your customers data and the business data from attack. I just want to highlight one thing that happened last year. In the UK, there was an attack on a broadband supplier, telephone supplier, for the home called TalkTalk, and the attackers were not professionals by any since of the imagination. They weren’t NationStates. They weren’t professional cyber criminals. They were just a bunch of people at home playing with security tools that they found on the Internet. There was a denial-of-service attack against TalkTalk, so he launched a multiple request against their portal and then they used that denial service to distract TalkTalk from the SQL injection that was going on, and supposedly, they used a tool called SQLMap to do the actual attack and steal the data of God knows how many customers, and they’ve lost something like, I think, in the region between £30 million to £60 million worth of business as a results. You know, in lost revenue. It is quite a small fry for a lot of businesses. They could probably absorb a lot of the cost, but the reputational damage was huge. They’ve lost a lot of reputation here in the UK, that company. I follow a blog called, hackmageddon.com, and that has a timeline of the most recent significant attacks, the sorts of data that was stolen, and the types of attacks that were used. It’s a fairly good indication of the types of things that are happening out there in the real world and where the attacks are coming from, based on the IP address of the attacker. So, they can tell you where the attack was coming from inside the U.S. or from Europe or from Russia or China or North Korea or wherever. So, most of the traffic does go between Russia and China and the United States. There are some attacks coming to and from Europe, but most of the traffic is between China, Russia, and the United States. So, there are attack maps you can see.

PERZE ABABA: You know, I believe a lot of CDNs actually have this feature too now, where they can actually look into, they plug in like a web application firewall in between for all of their web properties, and then you can actually see where the threats are coming. Then, based on country data, you can at where it’s coming from and where it’s going to and then you can create a visual model of it.

DAN BILLING: If you can visualize it in a way that’s exciting to people, it actually engages them more with the problem, I believe, and the maps are really a good way of doing that.

MATTHEW HEUSSER: For what it’s worth, I totally agree with that. I think I’ve said this before, maybe not on this podcast, I never got mind maps. I had a really hard time with mind maps for a really long time. Everyone was like, “Mind map are the new hotness.” “Yeah. They’re a way to represent test ideas. It’s fine. I don’t have a problem with representing test ideas or brainstorming now. I’m pretty good with a bulleted list,” and then I saw the value they have in communicating and visualizing what you’re doing for other people and I imagine the same thing with the attack. Like, “Wow. There’s a lot here. We should probably do something about it. How many of those land in Cambridge, Maryland or Hampshire, England. That, in and of itself, is just a powerful message to create a conversation. So, in the case of mind maps, the conversation is about, “What are risks we’re not worried about? What are risks we don’t think are worth investing in? What are the risks we are worried about?” They actually change the conversation from, “0 to 1 binary. You’re done or you’re not done. When are you going to get done?” To, “Oh, there’s an infinite number of ideas here,” if you’re triaging your time.

DAN BILLING: I find that mind mapping actually helps me a great deal when I’m trying to explore an application for the first time from a security point-of-view, because it allows me to see visually the different layers and pages that sit under what pages, what functions sit under which pages and functions, and then also how I can link sets of data together with the page itself. So, I know what tables are being queried. I can then, perhaps, structure and attack based on, “Can I create data or delete data through SQL injection, for example?” You know, visualization really helps me there, and actually, when I come to do training internally, I use mind mapping to structure the responses back from the team and link them together. So, I find it a very useful tool. It’s not just a security, but you know. It doesn’t suit everybody, but it does suit me.

MATTHEW HEUSSER: Well, let’s switch a little bit and talk about other aspects of security like simulating a phishing attack to see who will click on it.

DAN BILLING: Yeah.

MATTHEW HEUSSER: Dropping USB sticks in the parking lot to see who will stick them in their computer. Calling people up and pretending to be the Help Desk and try and get their password.

DAN BILLING: So, what you’re talking about here is social engineering?

MATTHEW HEUSSER: Yeah. I mean, social engineering is definitely in there. They’re all ways of changing the attack service from a technical one to a social one. I guess so, yeah.

DAN BILLING: I did a small workshop at Let’s Test in Sweden earlier this year on Social Engineering. What that focused on is, “The weakest link in any system or piece of software or service is the human being, either the human being that built it or the human being that’s using it.” You used a couple of examples there, “phishing attacks.” They’re quite easy. It’s quite easy to craft a malicious e-mail and send it out. I’ve heard of it being done inside companies to see, “Who’s paying attention to security warnings and e-mails and things like, who’s clicking what, are they just ignoring the warnings about what they’re doing? Are they checking the URL that they’re being passed through to? Are they actually sending data they shouldn’t be sending?” That kind of thing. And then, “dropping USB sticks.” People will pick that up and not think twice about sticking a USB stick into their computer, because they think, “Oh look, it’s a free USB. Let’s find out what’s on there. Does it have some cool stuff on there? Is there something I can sell?” Or using people’s—I hate to say it—often, self-interest and greed, also their lack of knowledge, quite often, it’s something people praying on vulnerable people as well. For example, telephony-type social engineering, sales people use it legitimately to generate sales and secure their sales wins all the time. So they say, “Hey, we’ve got this awesome product. We think it will work for you,” and they’re using social engineering techniques to get you to get interested in and buy their product. It’s the same when someone is trying to get you to divulge information about yourself or your business.

So, someone comes up to the receptionist at your building and says to them, “Hey, I’ve got a package for X and Y,” and they look like a legitimate delivery person. Or, they get the person who the package is intended for to come to reception and sign for it there. What they shouldn’t be doing is letting those people into the building. Let’s say, for example, you’ve got decorative plants in the building just to make the place look nice and you might have someone who comes in to tend those, and then they could be looking around, looking for things to steal, or information to gather. Equally, it could be the guy or the lady coming in to repair the printer. Social engineering is a major problem. I think it will become more of a problem because the Web is increasingly the way we communicate. So, you know, it’s something we all need to be aware of, but I don’t want everybody to be so frightened that they don’t want to go out their front doors. You know, we still need to go out and interact with people and be part of the communities that we live in. We shouldn’t be afraid of learning about the world out there just because there might be people out there that want to harm us. I can point you to some great resources in social engineering. I think it’s socialengineer.org, and there’s some great work by chaps like Christopher Hadnagy and Kevin Mitnick. Every year in, I think it’s Las Vegas, they have DEFCON where they do social engineering hacks as teams.

MATTHEW HEUSSER: So, you’ve done this testing, you did the OWASP thing, maybe you go to a conference or two, maybe you go to Black Hat, maybe you take some training. You learn how to use that attack proxy. You learn how to use the port scanner tools to figure out the products that are running on the server and then go after those. As an internal person, how do you get the confidence? When do you know that you can say, “Based on an audit using known security flaws and standard Pen Testing Methodology, we believe that this company has provided sufficient evidence that their security is acceptable for a financial regulation sign on it?”

DAN BILLING: My organization is PCI compliant, but it takes a lot of work for us to get there. We have quarterly scans that we have to do. I run my security scans on a weekly basis. Different organizations will identify different levels of risks for themselves. So, if you’re talking about financial organizations, they’re insured up to the hilts, but they also have a lot of regulations that cover them. I think that the world of security testing, security specialists, have pitched themselves at the compliance regimes that are supplied to. So, you know, we’ve mentioned PCI, but there a whole bunch of others—like SOC and SOC 2 to do with finances and HIPAA, which is a U.S. one to do with health data. You know, we’re under European Law, Data Protection Law, and then we also have our own Data Protection Law in the UK. So, we have to be subject to multiple different levels of scrutiny, as long as you can provide evidence that you’ve done the testing that you said you do and that testing is adequate or more than adequate, to describe the testing that was done. The problem is that a lot of people think that, once you’ve done the security testing, that your application is 100% secure. That’s a fallacy. That’s never going to be. That’s why I generally follow frameworks like STRIDE, for example. It’s a threat modeling process device by Microsoft for identifying threats to systems. OWASP has the OWASP ASVS and it can sit inside or alongside any of the compliance regimes that you have. One of the things, we are challenged with as testers, and not just security, is making sure we answer to our businesses in terms of demonstrating the work that we’ve done to ensure that the quality is there, and one aspect of that is security. I think it’s always going to be a challenge for us as testers to do that, and people have been talking about it ever since I’ve become a tester—in 15 years and far, far longer. We hear about breaches and attacks much more often on the Web, and it’s becoming much more in people’s radars. I think we need to be much more aware of it then we were. I mean, I’ll say this now, if anyone who’s doing 30 Days of Testing, wants to come and, you know, spend time with me, talking to me on Skype, or hooking up a meet-up, or something like that to learn about security then they, you know, all they have to do is e-mail me or find me on Twitter, and they can do that. I will happily talk to them about it and share my thinking and ideas and techniques with them.

PERZE ABABA: What approaches have you had in actually communicating security issues and contacts? Is there a scoring system that we can look at for the vulnerabilities, so that everybody can have a basic understanding on, “What’s important? What’s not important?”

DAN BILLING: So, there’s a number of things that you can use to help gauge that, Perze. There’s the OWASP Top 10, which is The Top 10 Web Application Vulnerabilities. If you’re hitting all those top 10, then you can have some confidence, but that’s just web applications. There’s also an OWASP Top 10 for Mobile Applications, and there’s also the CVE Top 25 as well. You can test for stuff that’s beyond the OWASP Top 10—like remote code execution, which is quite a challenge. The Application Security Verification Standard Project. So, OWASP ASVS, and it has different levels of severity checking that you can do. Unlike, say, for example, ISO Standards and things like that, it’s entirely voluntary. So, you can pick and choose the bits that work for you, and that gives you kind of a stage 1, stage 2, and stage 3. Stage 3, being the hardest to achieve. One of the things that I have done, apart from running various meet-ups and talks and workshops, is I created a mnemonic, which helped me when I first started security testing. As some of my friends and colleagues know, I’m a big Dr. Who fan, and in that show that have a villain called the Daleks, who are a cybernetic race of aliens, and their battle cry is, “Exterminate.” So, I used that word to help me build a mnemonic for security testing. It’s a word I’ve known for a long time, thanks to that show, and it’s a word that I won’t forget. “Ex” is “explore.” So, using my exploratory techniques to help me find issues. “T” for “threats.” So, it helps me identify the particular threats to an application. “Experiment.” So, that’s not just experimenting in terms of the testing that I’m going to do, but also tools and techniques. Also, any learning that I might have done and trying this out to see how it works. The next one is “R” for “risks.” Identifying risks and managing risks. The “M” is “monitor.” Not just from a testing point‑of‑view, but also from an operational point-of-view. The “I” and the “N” is “interrogate.” So, asking deep, hard questions of your applications. “Analysis.” So, that’s understanding the data that comes back from a security scan, for example. You’re going to have false positives, and you’re going to have actual bugs in there.

So, it’s a case of sorting the wheat from the chaff. The next one is the “T” is “targeted.” So, that is essentially aiming your testing at a specific target rather than allowing it to harm other areas without care and attention. The last one is “expedited.” So, the “E” is doing it quick. You know, there will always be someone running an attack somewhere from an automated system or they’re doing it up late at night or whatever. So, as soon as a patch comes in from, say, Microsoft or wherever else, you need to quickly patch those and also identify where the vulnerabilities area, if you’re unpatched. That’s my mnemonic. I hope that’s helpful. That’s one quick way I’ve found of visualizing and communicating security issues for testers and testing. That’s it. Thank you, gents.

MATTHEW HEUSSER: Okay, Dan. This has been great. Thanks everybody for coming, and we’ll be talking to you soon.

JUSTIN ROHRMAN: All right. See ya.

PERZE ABABA: See ya. Thanks everyone.

DAN BILLING: Bye.

[END OF TRANSCRIPT]

Security Testing

share

Panelists:

References:

Transcript:

Recent posts