WEBVTT

00:00.109 --> 00:03.465
>> Software development
activities.

00:03.465 --> 00:06.390
The learning objectives
for this lesson are to

00:06.390 --> 00:09.105
define formal methods of
integrating security,

00:09.105 --> 00:11.325
describe testing approaches,

00:11.325 --> 00:13.965
describe continuous
delivery methods,

00:13.965 --> 00:17.160
and to evaluate web
application security concepts.

00:17.160 --> 00:20.510
Let's get started. This is

00:20.510 --> 00:22.280
the software
development life cycle,

00:22.280 --> 00:23.810
it begins with planning.

00:23.810 --> 00:25.370
This is where all the ideas and

00:25.370 --> 00:27.440
requirements are put together

00:27.440 --> 00:31.820
to have a formalized idea of
what you want the app to be.

00:31.820 --> 00:34.225
From there, we take
it to the solution,

00:34.225 --> 00:37.520
this is where the formal
requirements for the app are

00:37.520 --> 00:38.750
taken from everything that

00:38.750 --> 00:41.135
was done in the planning stage.

00:41.135 --> 00:43.250
Then we move to the
coding stage where

00:43.250 --> 00:45.500
the requirements are built.

00:45.500 --> 00:47.330
The actual coding will take

00:47.330 --> 00:49.475
place here to
develop the product.

00:49.475 --> 00:51.890
Once the product is
ready for testing,

00:51.890 --> 00:53.810
we will move to
the testing stage.

00:53.810 --> 00:56.180
This is where the app will
be put through its paces to

00:56.180 --> 00:58.970
make sure that it lines
up with the requirements.

00:58.970 --> 01:01.370
Finally, we move to release,

01:01.370 --> 01:05.490
this is where the product is
released to the end-users.

01:06.040 --> 01:09.610
However, the current software
development life cycle

01:09.610 --> 01:12.565
has its limitations as far
as security is concerned.

01:12.565 --> 01:15.770
Security isn't added into
every part of the cycle,

01:15.770 --> 01:17.660
it's usually an afterthought

01:17.660 --> 01:19.670
that is bolted on afterwards.

01:19.670 --> 01:22.640
This is a very
dangerous approach for

01:22.640 --> 01:25.340
software development
because there

01:25.340 --> 01:27.680
could be fundamental issues
with the product from

01:27.680 --> 01:29.030
the very beginning
that cannot be

01:29.030 --> 01:31.355
addressed by security
on the back end.

01:31.355 --> 01:35.030
In addition to that,
our current SDLC

01:35.030 --> 01:37.160
lacks a formal
approach to adding

01:37.160 --> 01:40.080
security into the
creation of new apps.

01:41.660 --> 01:46.125
Testing approaches,
regression testing.

01:46.125 --> 01:49.685
When you're developing
software and you make changes,

01:49.685 --> 01:52.040
did any of the changes
cause previously

01:52.040 --> 01:54.635
existing functionality
or features to fail?

01:54.635 --> 01:57.470
This is what regression
testing will let you know.

01:57.470 --> 01:59.585
Next we have unit testing,

01:59.585 --> 02:02.825
this makes sure that a
block of code performs

02:02.825 --> 02:06.530
exactly what it was
supposed to do.

02:06.530 --> 02:09.590
If it was supposed to
perform this function,

02:09.590 --> 02:11.810
then you want to make sure
that it only performs

02:11.810 --> 02:12.890
that function and it does it

02:12.890 --> 02:14.705
exactly the way
it's supposed to.

02:14.705 --> 02:17.280
Next, we have
integration testing,

02:17.280 --> 02:18.830
this is where we take individual

02:18.830 --> 02:20.540
components and then we test

02:20.540 --> 02:21.950
them together to ensure that

02:21.950 --> 02:24.540
they work together as expected.

02:25.960 --> 02:29.010
Development approaches, first,

02:29.010 --> 02:30.945
we have the waterfall model.

02:30.945 --> 02:33.425
The key to remember
about this is,

02:33.425 --> 02:35.125
you have to complete

02:35.125 --> 02:38.185
each phase before moving
on to the next one.

02:38.185 --> 02:41.465
Because of that waterfall
is considered very rigid.

02:41.465 --> 02:43.855
Code checks are
performed at the end of

02:43.855 --> 02:46.270
each phase before you
can move on to the next.

02:46.270 --> 02:48.820
We start with the
requirement phase,

02:48.820 --> 02:51.955
then the design,
then implementation,

02:51.955 --> 02:55.130
verification and
finally maintenance.

02:56.570 --> 02:59.080
The next development
method we will

02:59.080 --> 03:01.240
discuss is the spiral method.

03:01.240 --> 03:03.220
Development has been modified

03:03.220 --> 03:04.780
continually through the process

03:04.780 --> 03:08.095
from stakeholder feedback
a product is released,

03:08.095 --> 03:09.370
receives feedback, it is

03:09.370 --> 03:12.070
modified and that's
a continual cycle.

03:12.070 --> 03:17.020
Risk analysis performed
at each interactive step.

03:17.700 --> 03:22.540
It's well suited for
large complex projects.

03:23.600 --> 03:26.640
Next we have the Agile model.

03:26.640 --> 03:29.590
This uses iterative processes

03:29.590 --> 03:32.425
to release well-tested
code in smaller blocks.

03:32.425 --> 03:35.870
Development is considered
to be continuous,

03:35.930 --> 03:39.940
it is adaptive to allow
for changes throughout

03:39.940 --> 03:43.510
the process and it focuses
on rapid deployment,

03:43.510 --> 03:45.490
often at the expense
of security.

03:45.490 --> 03:48.310
The thing to keep in
mind about Agile is they

03:48.310 --> 03:51.295
want it fast and
it's always moving.

03:51.295 --> 03:55.100
It's not rigid like the
waterfall method is.

03:56.720 --> 04:00.155
SecDevOps, there are

04:00.155 --> 04:02.735
two main requirements
for SecDevOps.

04:02.735 --> 04:04.685
The first is security as code,

04:04.685 --> 04:07.850
this uses automated methods for

04:07.850 --> 04:11.525
static code testing and
dynamic application testing.

04:11.525 --> 04:14.315
We also have
infrastructure as code,

04:14.315 --> 04:16.550
uses configuration
management tools

04:16.550 --> 04:18.574
to control code changes.

04:18.574 --> 04:22.080
Examples of this would
be Puppet and Ansible.

04:22.120 --> 04:25.850
You want to consider
requiring security to be

04:25.850 --> 04:28.970
included in all decisions
plans and coding.

04:28.970 --> 04:32.120
It requires developers to
have strong understanding of

04:32.120 --> 04:34.880
possible vulnerabilities
and must

04:34.880 --> 04:37.115
use version control
for code changes.

04:37.115 --> 04:40.040
Following this process
ensures that you

04:40.040 --> 04:42.170
develop secure code from

04:42.170 --> 04:45.035
the outset all the way
through to deployment.

04:45.035 --> 04:47.660
This is a much more
time-consuming process

04:47.660 --> 04:48.935
and also requires

04:48.935 --> 04:50.960
deeper understanding
of what you're trying

04:50.960 --> 04:53.910
to do and how that
works with security.

04:54.710 --> 04:57.060
Instructor side note.

04:57.060 --> 04:59.825
You might want to look at
Ansible for your own network,

04:59.825 --> 05:02.345
it's not just useful for code

05:02.345 --> 05:05.570
and for code management,
that type of thing.

05:05.570 --> 05:08.105
It will also allow
you to rapidly deploy

05:08.105 --> 05:11.675
configurations or keep devices
at a specific baseline.

05:11.675 --> 05:14.120
Ansible makes use of playbooks,

05:14.120 --> 05:15.290
and these can be deployed for

05:15.290 --> 05:17.045
configuration
management and updates.

05:17.045 --> 05:21.845
For example, if you're
deploying many Linux servers,

05:21.845 --> 05:24.499
you can use an Ansible playbook
that will automatically

05:24.499 --> 05:25.700
configure that server to

05:25.700 --> 05:28.145
the standard or the baseline
that you're looking for.

05:28.145 --> 05:29.810
It will ensure that it has

05:29.810 --> 05:32.690
the specific apps that you're
looking for installed,

05:32.690 --> 05:34.280
configuration
changes, that type of

05:34.280 --> 05:36.550
thing done
automatically for you.

05:36.550 --> 05:38.810
I use Ansible to keep all of

05:38.810 --> 05:41.255
our devices up-to-date
and current,

05:41.255 --> 05:42.710
and also to make sure that

05:42.710 --> 05:44.555
they stay at a certain baseline,

05:44.555 --> 05:47.370
that things aren't
deviating from that.

05:48.110 --> 05:50.955
Continuous delivery methods.

05:50.955 --> 05:53.565
First we have is
continuous integration

05:53.565 --> 05:57.355
DevOps should commit
and test updates often.

05:57.355 --> 05:59.820
Next we have
continuous delivery.

05:59.820 --> 06:02.405
Testing the infrastructure
that supports the app,

06:02.405 --> 06:05.770
networks, databases, client
software insecurity.

06:05.770 --> 06:08.160
Next is continuous deployment.

06:08.160 --> 06:10.850
This utilizes configuration
management tools to

06:10.850 --> 06:15.205
make changes to the
production environment.

06:15.205 --> 06:17.960
Finally, we have
continuous validation.

06:17.960 --> 06:20.180
Feedback from delivery
and development

06:20.180 --> 06:22.430
is monitored and
evaluated to ensure

06:22.430 --> 06:25.050
goals are meeting user

06:25.050 --> 06:30.509
needs this also must stay
with secure config baselines.

06:32.860 --> 06:36.180
Web Application
Security Concepts.

06:36.180 --> 06:39.590
OWASP, or the Open Web
Application Security Project is

06:39.590 --> 06:41.180
something you really
need to get to know if

06:41.180 --> 06:43.115
you're developing
web applications.

06:43.115 --> 06:45.890
They are a non-profit
online community that

06:45.890 --> 06:49.250
creates an publishes guides
for secure app creation.

06:49.250 --> 06:51.245
The next thing you
want to consider is

06:51.245 --> 06:53.340
HTTP headers these are

06:53.340 --> 06:55.565
security options they
can be set in headers,

06:55.565 --> 06:57.785
returned by a web
server to a client.

06:57.785 --> 06:59.180
There are quite a few of them,

06:59.180 --> 07:00.785
but some of the examples are

07:00.785 --> 07:03.395
HTTP Strict Security Transport,

07:03.395 --> 07:06.230
DSTS, X- Frame Options,

07:06.230 --> 07:10.830
XFO, X-Content-Type-Options
and others.

07:10.830 --> 07:14.030
OWASP also has their own
secure headers project,

07:14.030 --> 07:15.560
these are recommendations for

07:15.560 --> 07:18.485
HTTP response headers
for increased security.

07:18.485 --> 07:21.590
You can get all their information
at the OWASP website.

07:21.590 --> 07:23.690
Also keep in mind
that Cybrary has

07:23.690 --> 07:25.850
their own course
on the OWASP Top

07:25.850 --> 07:27.020
10 and these are

07:27.020 --> 07:30.960
the most common vulnerabilities
for web applications.

07:31.550 --> 07:34.220
Summary, we went

07:34.220 --> 07:36.350
over integrating security
into development,

07:36.350 --> 07:39.335
we also discussed software
testing approaches.

07:39.335 --> 07:41.840
We went over continuous
delivery methods

07:41.840 --> 07:45.180
and then Web Application
Security concepts.

07:45.620 --> 07:49.515
Let's do some example
questions. Question 1.

07:49.515 --> 07:51.590
Which development model uses

07:51.590 --> 07:54.380
interactive processes to
really smaller blocks

07:54.380 --> 07:57.090
of code that had
been well-tested?

07:57.350 --> 08:00.285
This is the Agile model.

08:00.285 --> 08:04.530
Question 2. What organization

08:04.530 --> 08:06.350
publishes a top 10 list of

08:06.350 --> 08:09.570
the most critical
application security risks?

08:10.160 --> 08:15.465
OWASP. Question 3.

08:15.465 --> 08:16.910
Which stage of the software

08:16.910 --> 08:19.880
development life-cycle
is responsible

08:19.880 --> 08:20.930
for gathering all of

08:20.930 --> 08:22.490
the necessary information on

08:22.490 --> 08:25.170
how an application
should function?

08:25.400 --> 08:28.590
Planning and
requirements gathering.

08:28.590 --> 08:30.855
Finally question 4.

08:30.855 --> 08:34.340
Which type of testing seeks
to find if any changes in

08:34.340 --> 08:37.640
code have caused previously
existing functions

08:37.640 --> 08:39.840
or features to fail?

08:40.250 --> 08:43.280
Regression testing. I hope

08:43.280 --> 08:44.540
this lesson was useful for

08:44.540 --> 08:46.860
you, and I'll see
you in the next one.