An industry thought leader, security subject matter expert, a published author, speaker and guest lecturer, Curtis Dalton is North America Managing Director, Security Strategy & Risk, at Accenture. An executive with over 25 years of experience, including managing budgets in excess of 100M and teams in excess of 85 people within the technology, financial services, and health industries.
His exposure to top-tier organizations has helped him become adept at establishing and conveying a fit-for-purpose vision and approach for the business. Curtis possesses a strong, first-hand international business experience with particular experience within the U.K., Germany, China (mainland), Hong Kong, Japan, Singapore, India and Australia. I understand the cultures, the people, the business environment and how to successfully navigate within them.
What are some of the popular and effective techniques that security leaders generally use to assess a threat landscape? What are the kinds of tools and techniques that are often used?
Well, I can’t mention anyone else’s tools, but I can mention some of things that we do. To assess threats and the threat landscape, we use i-Defense (a company we acquired). What i-defense does, is provide our clients with threat intelligence into what their indicators of attack are, what their indicators of compromise are within the environment. We then leverage that to better understand where certain incident response procedures should be augmented, where better detection is needed, and where better visibility is needed. All these technologies in the threat intel space are about improving visibility and improving your response capabilities. Everyone has already agreed that, eventually, someone who has enough time, resources, and skills will get in. There are certainly plenty of factions in the criminal world that have the capability, the skills, and the time. They can spend a year and a half trying to ascertain how best to breach a particular target. So, really our fall back mechanism is more visibility. That means better detection, better understanding, better context about what’s going on in the environment and correspondingly, being able to quickly respond. You want to minimize that threat window. The threat window stretches from the time you become vulnerable to something, to the time in which you are able to respond and address it. You want to minimize that threat window as much as possible and without threat intelligence, that job is very difficult.
Do you believe i-Defense nullifies the intervention of any human is possible?
No, absolutely not. No solution nullifies the need for a person. You always need people. This is why it’s great to be in security field. Security keeps stepping up. Attackers become more and more savvy, and their attack capabilities become more and more dangerous. The well-used paradigm where all attackers have to do is be right one time, while defenders have to be right every time. So comparatively, it’s relatively easy for them and difficult for us. With the advent of machine learning and artificial intelligence, we are better able to defend ourselves, but frankly the attackers are using these as well. There have been studies in the last handful of years which indicate that attackers actually collaborate better than defenders. The bad guys collaborate better than we do. They are more willing to share information and work together. That’s a problem because collaboration really leads to things like innovation. We are seeing lots of attacks today that are highly innovative.
How important are application security engineers to any organization?
I actually wrote a paper about this a few years ago. The whole point is that information security is really about protecting the data. If you think about it, what medium is closest to the data? The application collects the data, processes it, and shares it. The application is the closest medium that we have aside from the data itself. Eventually, we’ll get to the point where data can protect itself, and that will be a great moment, but we are not there yet. As long as the data can’t protect itself, the closest medium that has most context about the data is the application. So application security is critically important because that is the component that collects the data, moves the data, makes decisions about where to send the data, makes decisions about who has access to the data. So application security is really critical. This could become a whole conversation in and of itself. This involves the SDLC process, all the best practices that we should follow throughout the SDLC process, training of developers, validating third party libraries, etc. Third party code is an interesting one because they are represented heavily in applications today. The reality is that approximately 80% of an application’s library set is third party code. So, while we stress the importance of application developers becoming well versed in secure coding practices, the reality is that most of their job is not actually about writing code any more, it’s about assembling code. Software developers have strict schedules. They have to develop code very quickly to get something patched, add new features, get to the next release, etc. Under all of these pressures, they need to get that code over the line when it’s due. In today’s world with continuous integration and deployment methodologies, these things are very rapid.
When a developer sits down to write a code, do you think there is more focus on speed at which the code is deployed or the security portion occupies substantial importance there?
I guess it depends from organization to organization. A lot of application developers these days, for example, use a DevSecOps model. When it’s done properly, both speed and security are baked in. I think there are still many application security developers who haven’t been trained properly in secure coding practices. Despite the fact that so many libraries that end up in the application weren’t even written by your developers, they still need to be trained to identify weak code and know how to fix it.
What kind of financial impact do you think an organization will expect if they don’t follow a secure SDLC process vis-a-vis they are following it?
The facts and figures indicate that retrofitting security into an application could cost upwards of 300% more than if you did that way initially. You have to think about how complex apps are these days. It’s even complicated sometimes to identify really what an app is. You have all kinds of technologies that have pieces of the application all over the place, so it’s complicated.
Do you think that there is a dearth of application security engineers in the industry today?
It’s a function of what an application security engineer does. I would say SAST testing and largely even DAST testing can be done quite quickly if you do it right, so they really don’t need to know a lot about how these tools work. What is more important is to make sure they understand secure coding practices. Now a very important piece of this is when software developers are writing the code, it’s really useful to have SAST testing done in real time, so as the developers are writing their code, they can test it and immediately see the results. This becomes a valuable learning exercise to see the results from a SAST test and to make those adjustments right away while things are fresh.
Are you saying that there is very less need of app security specialists who can work towards a secure SDLC?
No, I think it’s more of the opposite. You should have a security architect involved in the SDLC process to think about the bigger picture, and how everything fits together. The security architect is basically the security champion for a given project. This is someone with IT skills, application security architecture skills as well as a good understanding of SDLC processes. This person is kind of a liaison that overlaps between Dev and the Ops. He or she provides the right level of security expertise, and will work with the software development team from the beginning. They begin by making sure that what they are going to develop is going to be architected with security in mind and as certain milestones are achieved/ about to be achieved. It is important to have continuing security architecture reviews to make sure that what was intended in the design has been fulfilled in the code. So, I am not saying don’t train your software developers in application security architecture and testing, but don’t expect software developers to be IT security experts capable of Pen testing and DAST testing. Let them focus on writing their code in a secure fashion. They are already heavily taxed with the heavy workload and timelines. Let them focus on learning secure coding practices. I have in the past created a belt system of training in application security. Automatically, you start off at white belt and after taking certain trainings and conducting certain experiential exercises, you achieve more belts and that is how you move from white to yellow belt, to green belt, to purple belt, to brown belt, and ultimately black belt. The idea there is to build a doctrine and program that steers you towards security improvements. What I did was institute a requirement that for example only people with the highest levels of secure coding practices got to work on projects that handled sensitive information. These in effect are the most interesting and cool projects. If you don’t have the required belt level, you would not be able to work on that cool project and instead they would work on the more mundane projects. You should build your program in such a way that it inspires the software community to become more security minded and that is one of the CISO’s top responsibilities — to build a security mindset throughout the organization, imbedding it within the culture itself.
What kind of training programs are generally conducted in Accenture or in your past organization toward ensuring that aspiring security analysts can be trained?
Accenture has a vast amount of internal trainings that cover a wide topic base, and also a good mixture of industry training as well. In a way, attending the key conferences like RSA, BlackHat, Defcon, etc., and networking with people outside your organization are very important too. It’s about sharing information, and getting different perspectives.
Is there any specific set of skills which according to you is a must have for somebody to be Application Security Engineer?
So again, when you say Application Security engineer, I am imagining that that person is going to be really a security person at heart. You can take an application developer and teach them security more easily than you could take a security person and teach them application development.
In an ideal scenario, if someone were to become an app security engineer, what are the skills you would expect him to have at your level?
They have to understand how applications function, application architecture, the different tiers, etc. They have to understand those basics, SDLC, and then on top of that, they need to have some past skills in software development. Enough experience just to get their feet wet effectively. Understanding of the SAST toolsets and the DAST toolsets, all the different open source application security testing tools, and understanding also how to eradicate false positives from your test results is the key. And understanding how to security test applications and systems without impacting productivity when it is not appropriate is also important
How someone at your level will rate a course on AppSec training? We are rolling out a course which is called CASE, so if I tell you about these courses what are the necessary skills you think should be in a course like this?
Well I think fundamentals of application architecture to my point earlier understanding how they are architected, how do you do an application architecture review that’s important for understanding the inputs and outputs, how the application should process things, have to understand obviously encryption, how to use it, how to apply it, have to understand SDLC as a whole, understanding when to plug in and what to plug in for certain testing and what the end results would be.
When it comes to safeguarding companies from cyber threat from the outside we see a lot of menace in the form of insider threats, what does a large company like Accenture do to counter these threats?
In general, what you want to do is implement a zero-trust model, as much as possible. In zero trust, there are basically four pillars: validate the user’s input into the application, validate the user’s device, and control the user’s access throughout their session. Creating an active authentication scheme like this is really valuable. This is related to an ability Accenture has within its identity management practice – where we can actively authenticate and authorize a user. Effectively, we can monitor the user session for abnormalities and quickly take the needed actions such as terminating their access.
Traditionally, the security department in an organization reports to IT. However, we are now seeing a trend where IT reports to security. Do you think the latter is the right approach?
Frankly, I have never seen that but in general the world of the CISO has evolved. When I was global CISO at a previous company, I was hired in to work for the COO. Two years later, with the rise in the importance of privacy, I began reporting to the General Council. Security enables privacy, so it made a lot of sense to make that shift. At another previous company, I reported to the President/CEO. In both of my CISO roles, I was a peer to the CIO.
Do you think the cyber security practices followed today would be relevant in the next two years, what would your advice be to a budding infosec professional of today?
Yes largely they will. As much as we say that security in particular moves rapidly, application security has not changed so rapidly. We have relatively new forms of testing, such as IAST, but that has been around for several years and there are still many companies that don’t use it.
To a budding infosec professional, my advice would be to understand DevSecOps, understand the agile environment, types of security testing that should take place within the SDLC, know when to implement those tests and how to reduce false positive within those test sets.
