In this lesson, we're going to talk about
some administrative controls.
This includes role-based access control,
minimum password requirements,
policies and procedures,
and secure software development life cycles.
First, we have role-based access control.
Role-based access control is a security approach
that focuses on restricting the availability
of a resource to only authorize users.
Now, when we deal with role-based access control,
we are really focusing on the way
that we give permission and rights to particular users
based on their job function inside of an organization.
Role-based access control allows an administrator
to assign each user to one or more roles,
and then use those roles to assign the permissions
to the organization's resources.
In Windows domain environments, role-based access control is
normally going to be implemented
by using groups, and these groups can also be set up
in a structure that mimics your organization's hierarchy.
For example, we might create one group
for the Accounting Department,
and another group for the Human Resources Department.
Then based on those groups or roles,
we can assign each group with access
to different resources.
Additionally, we could put both of these groups
into a higher level group called, "employees,"
and that group might have access to other resources
that every employee of the company needs access to.
Role-based access control can be used
to enforce minimum privileges for that subject
based upon all of their associated groups,
and the different users can be members
of one or more groups based on the different roles
they fulfill within the organization.
This type of access control works really well
for organizations who have a high rate of employee turnover
because those permissions are going to be based
on a work role, rather than on an individual's own username.
Second, we're going to talk about
minimum password requirements.
Now, when we talk about the password policy itself,
this is an administrative control.
If we talk about the technical implementation
of these requirements, that then becomes
a technical or logical control.
But for the purposes here,
we're going to cover minimum password requirements
under administrative controls
because we're talking about the policy itself.
Now, a password policy is simply a policy document
that promotes strong passwords
by specifying an acceptable length,
complexity, character classes, history,
maximum or minimum age, auditing requirements,
and reversibility of your encryption.
Depending on how you configure your password policies
within your organization, your user accounts
and credentials will either be more
or less secure from being compromised by an attacker.
Now, for most of us, this is going to be a review,
but I recommend you don't skip this video
because there has been some big changes
in the world of password policies in the recent years.
Now, according to the NIST Special Publication 800-63B,
this is the Digital Identity Guidelines,
and it's going to be considered the source materials
for what should be implemented
in order to have a strong password security policy,
some of the traditional elements
of a strong password policy are now considered
to be deprecated or obsolete.
For example, let's consider the length
and complexity of a given password.
Ever since I started working in IT and cybersecurity,
we've been told that you need
to use a long, strong, and complex password.
This is defined as having at least eight characters,
or at least 12 characters, or at least 16 characters long,
and it seems to get longer all the time.
Now, in addition to this long password,
we've been told to have a complex password.
Now, complexity is defined
by having different characters being used,
such as lowercase letters, uppercase letters,
numbers, and special characters.
You see, if we just use lowercase letters,
then you'll only have 26 characters in your character set.
But if you use lowercase and uppercase,
you now have 52 characters in that set.
If you add numbers, we now have 62 characters in that set,
and if we had symbols, we're now somewhere in the range
of 70 to 80 characters in that given character set.
The more and different types of characters we use,
the more complex the password can be,
and this is always going to be considered
a stronger password, at least it was, historically.
Now, while that's true from a purely mathematical
and code-breaking perspective,
it neglects the fact that we have to account
for one important thing, human nature.
If my password is something like
!4rQ63%@aHwJ;2XA,
it is really long, strong, and complex,
but I'm never going to be able to remember that.
So most people would end up writing down
that password on a notepad
or even worse on a digital text file on their desktop.
So now, that long, strong and complex password
is simply out in the open
and can be retrieved by anybody, including attackers.
For this reason, the new guidance
in the NIST Special Publication 800-63B
states that you should no longer enforce complexity
as part of your password policy.
Instead, NIST recommends that passwords
should now be between
8 and 64 ASCII characters in length.
Your users can have a nice long password,
and they can use uppercase and lowercase letters
and maybe even some numbers
or special characters if they desire,
but those should not be required.
When it comes to security, having a long string
that is not repetitive is just as secure
as a complex 8-character password,
which is why the NIST no longer recommends
the complexity rules be enforced.
Another change in the latest NIST publication
is that maximum password age enforcement
is no longer considered a good idea either.
If you've been in cybersecurity for a while,
you're probably used to seeing most systems configured
to require a user's password
to be changed every 60 or 90 days,
but this is no longer considered a best practice.
Why?
Well, again, it comes back to human nature.
If we're asking people to create these long passwords
of up to 64 characters, even if it isn't complex,
it's going to be harder for them to memorize,
especially if they have to change it every 60 to 90 days.
So by allowing for a longer password age time,
it increases the chances
that your users will actually memorize their passwords
instead of writing them down someplace.
Another reason for this change in the enforcement rules
is that most people are migrating
towards the use of password or credential managers.
This allows them to create very long
and randomized passwords as their credentials,
and this leads to overall stronger passwords,
and these are going to be securely stored
by your password manager in an encrypted format,
where they remain secure until the user actually needs them.
If your users are using a password manager,
then there is less need for them
to have to change the password every 60 to 90 days,
and it minimizes the chances
of those passwords being compromised
because users are no longer subject to password reuse,
because every password manager will use a new
and unique password for each and every account
or website that that user is going to visit.
The other side of the coin here
when it comes to password age is the minimum age.
Now, minimum password age is a setting
that can be enabled in your password policy
that requires a certain number of days to pass
before a user can reset their password.
If you've set this to zero days,
that means your users can immediately change their password,
but if you set this to one day,
they have to wait 24 hours
before they can reset their password again.
Now, why does this minimum age of a password really matter?
Well, it really has more to do with the concept
of password history than the age itself.
Password history is a setting within your password policy
that dictates how many different passwords
have to be used before you can return
to a previously used password.
Let's assume I have a password history policy of five,
then I set my first password as password one,
and a few days goes by and I forget my password,
so I use the forget password feature to reset my password,
and I create it as password two.
But I really want to use my old password
of password one again.
So since I have a password age set of five, I can't do that.
Instead, I have to keep resetting my password
until I do this five times,
then I could reuse my old password of password one again.
Now, if my minimum password age was set to zero,
I could simply reset my password five times in a row
and go back to my initial password on the same day.
If this password was previously compromised
by a data breach, for example, this would lead
to a big vulnerability of my user credentials.
For this reason, it is a good idea
to have your password history setting
set to a really high number, something like 25,
because this will help prevent password reuse.
Third, we need to talk about policies and procedures.
Now, policies and procedures enable an organization
to operate normally while minimizing
their cybersecurity incidents.
There are lots of different policies
and procedures you can implement,
and we've already talked about some of them
when we talked about operational controls.
When it comes to policies and procedures,
this is going to allow you to be able
to set things like your mobile device management policy,
your remote access policy, your password policies,
and your role-based access control policies.
As a penetration tester, you should recommend
that the organization update its policies
based upon the vulnerabilities that you found
during your engagement.
Fourth, we need to talk about
the secure software development life cycle.
The software development life cycle
is the way that organizations create their own applications.
So if you've done an engagement against an organization
that creates their own applications,
such as web apps, mobile apps, or desktop apps,
you might be able to provide them
some recommendations as remediation actions
for any vulnerabilities you've found during your engagement.
Now, the goal of the software development life cycle
is to create a methodology
to predictably identify all the requirements
for a given piece of software,
to develop it, to test it, to release it,
and to support it throughout its life cycle.
The software development lifecycle consists of eight steps.
First, plan and initiate the project.
Second, gather the requirements.
Third, design the software.
Fourth, develop the software.
Fifth, test and validate the software.
Sixth, release and maintain the software.
Seventh, certify and accredit the software.
And eighth, perform change management
and configuration management for the software.
Now, during the planning and initiation phase,
the organization is formally going to begin
to develop the plans for this project.
As a security professional, it is imperative
that your interests are being represented during this phase
as you assess the expected results
of the software that's being planned
and determine what protections should be put into place
to safeguard the application and its associated data.
Now, additionally, all the data being handled
by the software should be classified and documented,
and this information is crucial
to creating the security requirements
and functionality needed for that given piece of software.
Next, the requirements are gathered
from across the organization or its customers.
Basically, this phase is going to be designed
to answer the question, what will this piece
of software need to do in order
to be considered successful?
As security professionals,
our goal during this phase is to ensure
that each and every security requirement
is being captured, so the software
can be written to account
for those requirements within its functionality.
The third step is to design the software.
At this point, the software designers
and the security professionals
are going to be working closely together
to determine the state of the application
and how it's going to achieve
the desired functionality and security.
The fourth step is to develop the software,
and this is the portion of the life cycle
where the programmers and coders
begin to actually write the code
that's going to enable all the functionality
that's been planned and designed so far in the life cycle.
The fifth step is to test and validate the software,
and this is going to be a very important step
and security professionals need to be involved here.
This is going to include not just the functionality testing
that the programmers are going to conduct,
but also vulnerability assessments
and penetration testing that's conducted
by your security team.
Once tested, the software should also be validated
in assimilated live environment within your lab,
which can mimic the true production environment
prior to release.
Validation testing is going to be used to verify
a system or application is meeting
the functional security requirements that were defined
by the customer in the requirements document.
Acceptance testing, on the other hand,
is going to be used as the final acceptance
of the system or application by your end users.
Both of these types of testing are extremely important
to utilize to verify the utility
and warranty of the system or application.
For example, if your application meets all the functional
and security requirements, but it doesn't get accepted
by your end users, then guess what?
It's useless.
In addition to conducting validation
and acceptance testing for your systems and applications,
you can also use validation
and acceptance testings for your different security controls
as you implement those within your organization.
Each security control being implemented
should be tested for its validity,
and also needs to be accepted by your end users,
otherwise they might attempt
to bypass those new security controls you put in place.
Software is often going to be developed in parts and pieces.
Now, each of these pieces should be individually tested
using unit testing.
This unit testing provides us with test data,
checks for input validation, verifies proper outputs,
and ensures that it's functioning properly and securely.
Once all of the units have been tested individually,
they need to be brought together
for integration testing too.
Integration testing focuses on the end-to-end experience
in order to validate and accept the complete system.
This type of testing is going to be focused
on functionality and security, not on your user experience.
Instead, user acceptance testing is going to focus
on the customer and the end user experience.
This testing ensures that they are satisfied
with the product and it meets their needs,
and that they understand properly
how to use the new product.
User acceptance testing is going to be critical
to getting widespread adoption of any new product,
service, or application.
The only real disadvantage to conducting this
is that it can add cost to your product
and time inside of your release schedule.
Another form of testing is known as regression testing.
With regression testing, any changes
to the baseline code is going to be evaluated
to ensure it does not reduce the security
or functionality of the current product.
This type of testing is crucial to ensure
that any new changes we're putting in
are being properly integrated,
that the product quality remains high,
and that there are no adverse side effects.
The final form of testing is known as peer review.
Under peer review, developers will review
each other's codes for efficiency,
functionality, and security issues.
This is a much more thorough review
than an automated testing method,
but it is more time consuming and more costly.
And this brings us to our sixth step.
This is where the software is fielded
and released into the production environment,
and at this point, the operations team
can take over responsibility for this piece of software.
This is the phase of the life cycle
where the majority of the software's life will occur.
The operations team is going to provide support
to our end users of the software,
and we're going to maintain the software
in a functional state.
If a security issue is discovered,
then a patch will have to be created and released
to maintain the security of that software.
The seventh step is to certify
and accredit the software,
which is going to ensure the software
meets the security needs of its customers.
The eighth and final step is to conduct change management
and configuration management.
This occurs when a change to the functionality, security,
or release date of the software has to be made.
This process is a formalized process
to ensure the integrity and security
of a given configuration item,
such as a system, a server, or a piece of software
to ensure that it's properly maintained over time.