-: Coding for security.
So we talk about all this stuff,
we've been talking about coding
in the software development process,
and I mentioned you want to get your
requirements in early if you are
part of the cyber security analyst team.
But if you're a programmer, how can you code
effectively for security practices?
Well, you have to make sure that those
requirements you got from our cyber security analyst
in the requirements phase are built during
design and coding in a secure method.
If you don't think about security until
after you've built the rest of your code,
it's already too late.
Security that's added in prototypes and final products
is just way too costly.
We want to build it in early on
before we ever get to market.
Because every time you have to think
about adding things in afterwards,
it's gonna cost you two and three times more
money and more time.
So, what are some great secure coding practices?
Well, you should have an organizational
secure coding policy.
They should have things like
how is it going to be documented?
How are you gonna test it?
All of those things, if you're a code developing agency,
you probably need to have a policy that
talks about how you're going to use best practices.
The next thing is you wanna conduct risk assessments
and ongoing assessments to prioritize
your issues that you want to remediate.
So as you're going through, almost like that Agile,
where you had all these different function blocks,
well, security should be like that.
You've gotta look across and go okay,
what are all the different pieces of
security we wanna add and which ones
are we gonna fix first?
And so if this is in the operations
and maintenance lifecycle, for instance,
and they find 10 different bugs in your product,
which one do you fix first?
Well you might fix the most critical,
or you might fix the one that takes the
least amount of time, or fix the one
that's gonna cost you the least money.
All of these things are things you have
to think about from a risk assessment
and ongoing assessment perspective.
Next, you wanna do user validation.
Every time you're taking input from a user,
you cannot trust it.
This is how you're gonna prevent Cross-site scripting
and SQL injection attacks.
Every piece of input you ever get from a user
should be validated.
If you're expecting text, verify that you got text.
If you're expecting a number, verify that you got a number.
If you're expecting a dollar sign, for instance,
you're expecting something that's less than $100,
and somebody puts $10 million,
is that gonna break your program?
Validate that input before feeding it into your functions.
Next you wanna consider your error messages.
We always put in error messages in our stuff, right?
And they might throw up a flag to your user,
to your end user.
Those error messages may have too much information
that allows me, the attacker, if I'm the end user,
to be able to see into your program code
and figure out how you're doing things and
use that against you.
So, you want enough information in the error messages
that it's helpful to the user,
but you don't want too much information
so that somebody can use that to
reverse engineer your product.
And then, you wanna use database security
in both the application side and the database side.
This is gonna help you prevent data leaks,
so you gotta think about that as you're
integrating these databases in and in
integrating these files in, how are you
going to secure them?
Some other good coding practices we use,
encrypt your sensitive information being stored.
Any data you're storing should be encrypted.
If it's a password, it should be hashed.
Because you don't want this stuff to be able to
be stolen by an attacker and then used
against your company later on.
You also wanna design for availability and scalability.
Now what do I mean by that?
Well, you ought to prevent things like
DDoS attacks, right?
Or, DoS attacks, right, denial of service.
That's an availability issue.
You do that by creating a lot of redundancy
inside your systems and processes
and you wanna make sure you're conducting
good load and stress testing to verify
your programs and your applications
and the infrastructure that support them
can support whatever the load is you're expecting.
Now, scalability, as we've gone into scalability,
we've gone into cloud resources like AWS
and Azure, it's allowed us to scale up very quickly
and that has prevented a lot of the denial of
service type issues going after that
stressing and loading, so you're gonna have to
figure out what those variables are and what
you wanna be able to meet.
Next, you wanna be able to conduct monitoring and logging.
I think we've beaten that to death in this course,
we've talked all about monitoring
and all about logging and how important it is.
And then you wanna use
multifactor authentication if possible.
So a lot of apps now are using where you're
gonna get a text message, you put in your
user name and password, you get a text message
back with a secret code and then you enter that in.
Or, use a token or use a RSA key fob,
or a Google authenticator.
We've talked about that in our identity lesson.
Again, utilize that inside your coding practices so that
the programs you're coding do have good authentication.
Some other things we wanna consider is you're
gonna code for secure session management.
This is gonna prevent session hijacking.
Don't use easily guessable sessions,
make it randomized when they're picking numbers,
if you're doing protocol development.
Proper cookie management.
If you're using website development here,
you wanna make sure you're securing the cookies,
because those can be used in web applications
and stolen by attackers.
You also wanna encrypt any network traffic you do.
Anytime you're sending data back and forth,
you should be using an HTTPS connection or a TLS tunnel.
And then you wanna also secure
your underlying infrastructure because
the application, no matter how good you code it,
if you put it on a development environment
that is not secure, somebody can get in there too, right?
As a cybersecurity analyst, you're gonna have the most
impact probably securing that underlying infrastructure.
Those servers and those programs,
not the code itself unless you happen to be
a programmer working in this field.
Now, one of the things I wanna talk about here
is called OWASP and that's the Open Web
Application Security Project.
This is a great website that you can
go to at OWASP.org and they have tons and tons
of information, they have things like
community hosted standards, guides,
best practices, and open source tools
that will help you get better at analyzing
web applications, coding your web applications,
and testing the security of web applications.
They provide updated lists all the time
of proactive controls to test your application security.
In fact, they have the OWASP top 10
that tell you the top 10 most common
vulnerabilities that they find inside web applications.
And those are updated about every six months to a year.
So I recommend checking out O-W-A-S-P, OWASP and
see if there's any information on there
that you'd like to go.
They also have a lot of things on there
as far as free scanners for your web apps
and other tools like that.
The last thing I wanna talk about here is
secure code management.
So your coders are gonna be using code all the time.
How do they know they're using the latest code
and fixing the bugs in the latest versions?
Well, they're gonna be using things like
checking in and checking out and revision history.
That way you know who touched the code,
who edited the code, and who changed the code.
So if you have an inside threat, for instance,
and you find out that Jason was the last one
to touch the code, then you start asking Jason
why he introduced that bug into the software, right?
Maybe I did it by accident, maybe I did it on purpose.
But you're gonna have to figure that out
if you're the cyber security analyst.
These code repositories are gonna allow
you to have some of that data to
go back and, as you're tracking down
where those bugs came from.
It's gonna tell you what the current
version of the code is and any revisions
that have been made.
There's a lot of different ones out there,
there's Git, there's Subversion, there's CVS.
And these are all called service control management
or version control tools.
As your coders are going through,
they should be using one of these
repositories so they can check in the code,
check out the code, and know who last
touched it and what is the most current
version that they're working on.
'Cause nothing is worse than going back
to a three month old code and start
changing it even though there's one that
was created last week that already fixed
the problems you're trying to fix.