Guidelines for developers are also important. You know, remember we may not always be around to offer developers guidance as to what they need to do to be secure, and they may not come and ask us, they may not be interested in doing that. They really just may be interested in writing code and doing it their way. When you start working with developers, you will find that a lot of them are very open, a lot of them are very interested in doing the right thing, creating secure code, and they want guidance, and you may be asked for that. It's very important for you to have something to say when somebody says, "Hey, can you help me?" And you want to be able to give them some general ideas of things that would be important. So we have a list here, not by any means going to be the total thing, total list out beyond anything else you should ever say, it is just a sampling of the different things that would be helpful. We should be thinking about things like authentication, authorization. Hey Mr. and Mrs. developer, how are you going to get user credentials into the system? How are you going to pass them to the back end for authentication? How are we going to deal with authorization? How do we deal with identity management in other words? It's very important. How do we set up and maintain a session? What are the ways in which we secure a session? Are we encrypting the data and the traffic? Are we tunneling? Are we using session timeouts? These are all things that would be important for developers to think about and for you to proffer as advice. How are we doing input validation? Are we allowing someone to sit down at a forum, type in unrestricted amounts of text, special characters, wildcards, etc? Probably not a really good idea if we do that as we were reading about or talking about just a moment ago in the OWASP top 10 list. As we were drilling into the injection, the A1 vulnerability, we would find that input validation is a very important mitigation tactic for injection attacks because if we don't validate our input, we potentially could allow injection attacks to occur because people may be able to throw code or malformed input into a system and in fact try to take over the system in some way or cause it to do things it's not supposed to do. Disallow dynamic queries, what are we doing with out-of-band communication? Are we integrating that? If we are, how are we going to use it? Remember, out-of-band communication may be the idea of sending somebody a code, a pin, something like that, through an alternate communication mechanism, maybe through e-mail registered ahead of time of course, maybe through a cell phone, by a phone call, or perhaps through a SMS or short text message, and then asking them to provide that code or that input to validate something before we allow them to continue. This is called an out-of-band communication channel. We may want to use that, and developers should be aware that and be told that that's a way to add a layer in security through defense and depth capabilities. Avoid exposing system information. Error codes are usually a really big issue here. Developers, a lot of times, will throw error codes into their system as they develop and say, well, if this happens, do this. But sometimes, if they're not careful and they're not paying attention or there's just so much going on and they don't realize it, those errors may actually expose, on the screen, system data that could be valuable to a bad actor. You may have seen this happen where you've gone to a web page sometimes or gone to some sort of front end where you're loading in data with the form, being asked to subscribe or do something, and you provide that, you hit submit, and instead of what you normally think you would see, the web page saying thank you or actually access to the system, you get some sort of yellow background, red text on the screen, kind of screen that has all sorts of errors stuff on it. It's basically an error screen. And what happened was that developer in their coding didn't hide the error in some sort of loop internally in the program and deal with it, they inadvertently exposed it. So when it happened, it popped up. When that happens, you're seeing the code that transacts to create the error and you're seeing the information about the system it's transacting in. And in many cases, if this is a database you're querying or a website you're trying to get to that's running with data from a back end, you may be throwing up inadvertently on the screen as an error information about what kind of database is back there, what kind of web server is there, what kind of connection are we using. We may even see a connection string that involves credentials. There's all sorts of stuff that can go horribly, horribly wrong here. And if we see that happen, we've given the bad actors some very useful information. So we don't want that to happen. So we want to make sure we tell them about that and deal with error handling. These are all things that developers need to be given guidance on. Remember, developers are really good at writing code. This is what they specialize in. They may or may not have been trained to write code securely. It's a very different approach than just writing code. And developers want to do the right thing, not implying they don't. Just pointing out that they may not understand how to code securely in all situations with all circumstances, and it's up to us the security practitioners to be able to offer them guidance, not about how to write code, that's what they do, but how to integrate security into the coding process to make the output more secure. That's something we can help them to do because that's what we specialize in. And in working together, we can achieve the end result we look for, which is secure systems, confidentiality, integrity, and availability is going to be built it in every step or every stage of the process. And ultimately, we're going to make sure that input and output are as secure as they can be, as well as everything that goes on inside the middle in the black box, where we're programming and we're processing. All those stages require focus, security, and ultimately, oversight to make sure they operate the right way. And we are going to specialize in those areas, that's what SSCPs do.
