A14 System Acquisition, Development and Maintenance

00:02

Listen 11.10,

00:04

a 14 system acquisition, development and maintenance.

00:12

In this video, we will understand control. Sit a 14

00:17

in relation to your ice mess. We will look at the different control areas as well as the controls that they contain

00:24

and go through some examples off evidence that could be requested by your auditor during audits,

00:36

Control said. A 14 system development,

00:40

my acquisition and maintenance

00:43

consists of three control areas.

00:47

The first area, a 14.1

00:50

security requirements of information systems,

00:54

consists of three controls.

00:57

These controls are

00:59

a 14.1 point one

01:02

information security requirements, analysis and specification.

01:07

So when you do your business requirements, analysis

01:12

and your systems specifications documents,

01:15

it is important to ensure that information security related requirements are identified and included in the requirements,

01:25

either for these new information systems or where enhancements to existing information systems are being made.

01:34

Evidence for this can include the requirements specification documents themselves,

01:40

as well as any guidance or procedure documents specifying how to identify security related requirements.

01:49

The next control is a 14.1 point two

01:53

securing application services on public networks,

02:00

so this control pertains to any information that is involved in application services

02:06

and which passes over public networks shall be appropriately protected from any fraudulent activity,

02:13

contract dispute

02:15

or unauthorized disclosure and modification.

02:19

So this kind of

02:20

entails security in any AP ICE that you are making use off,

02:24

ensuring that your application enforces secure transport over https and Tellis protocols,

02:34

BP ends

02:36

and so forth.

02:38

The last control in the first control area

02:42

is a 14.1 point three

02:45

protecting application services transactions.

02:50

This control pertains to any information that is involved in application service. Transactions

02:55

must be appropriately protected to prevent incomplete transmission,

03:00

any mis routing,

03:02

unauthorized message alteration,

03:05

unauthorized disclosure

03:07

or any unauthorized message, duplication or replay.

03:14

For this,

03:15

you would have evidence involving any policies or procedures pertaining to preventing

03:23

and protecting service transactions,

03:25

and the disclosure there are.

03:30

This would most likely involve the configuration of various controls in your databases

03:35

as well as theatric ations transmitting the service transactions.

03:40

Your order Thio here would most likely want to see if there have been any areas

03:46

how these adult with

03:47

and how the system handles

03:51

any exceptions

03:53

to the ways in which information should be protected.

03:58

The second control area

03:59

is a 14.2

04:01

security in development and support processes.

04:06

The first control

04:08

is a 14.2 point one

04:12

the Secure Development Policy.

04:15

This will entail a policy or some document that specifies rules for the development of software and systems

04:24

specifically with regards to security,

04:28

and that these air applied to developments within the organization.

04:33

A 14.2 point two

04:36

is your system change control procedures.

04:42

This control specifies that all changes to systems within the development life cycle

04:46

shall be controlled by the use of formal change control procedures.

04:51

This change management procedure may or may not be different from your overall change management procedure,

04:59

so be sure that you have either established a separate change management procedures specifically to us Telsey

05:06

or, if you leverage off your overall one,

05:10

just make it clear when the changes pertain directly to system changes.

05:17

The next control is a 14.2 point three

05:21

technical review of applications after operating platform changes.

05:28

This control basically means that if you're operating, platforms are changed. Whether you change operating systems or deploying new major patches or whatever the case is

05:39

that your business critical applications are reviewed and tasted

05:43

to make sure that there is no adverse impact as a result of your operating platform changing,

05:51

you're orderto will ask to see if there has been any evidence off this occurring during the period under review.

05:59

A 14.2 point four

06:00

restrictions on changes to software packages.

06:04

This control.

06:05

It's specific to modifications off software packages

06:10

on that, these modifications are discouraged, limited to necessary changes

06:15

and all changes being strictly controlled.

06:18

If your organization has an in house software development team,

06:23

you will most likely make use of some sort of code repository.

06:27

And these controls will help to enforce the restriction on changes to software packages.

06:32

Ensure that any rules around this are formally documented

06:36

and that these rules have been appropriately implemented on the software itself.

06:44

A 14.2 point five

06:46

secure system engineering principles.

06:49

This control means that you will basically have a secure systems development life cycle process.

06:57

The principles for engineering secure systems shall be established, documented, maintained and applied to any information system implementation efforts,

07:09

so this pertains to both in house developed systems as well as any off the shelf

07:14

or third party systems used.

07:16

It's basically coming down to ensuring that security is built in from as early as possible

07:24

in the process as possible

07:26

and not built on at a later stage.

07:30

A 14.2 point six

07:32

secure development environment

07:36

here. Your organization needs to establish and appropriately protect your development environment

07:44

to ensure that your development environment is kept

07:48

secure,

07:49

sound

07:51

and only appropriate and authorized personal. Have access to this environment.

07:59

A 14.2 point seven

08:01

outsource development

08:03

in any case is where your organization makes use of art. Source.

08:07

Outsource development.

08:11

Your organization needs to supervise and monitor the activity off the outsource system development.

08:16

It is also your organization's responsibility to ensure that the outsource service provider and here's to your organization's security principles and requirements.

08:28

A 14.2 point eight system security testing.

08:33

This boils down to the testing off security functionality

08:37

in your code, which is either being developed or in a system that you have procured and are implementing.

08:43

This needs to be carried out during development

08:46

as well as prior to implementation.

08:50

It basically boils down to a penetration test off the system

08:54

prior to the system being deployed in your network,

09:00

a 14.2 point nine system acceptance testing.

09:05

This is the acceptance testing program and related criteria

09:09

for new information systems upgrades and new versions.

09:13

System acceptance testing can be done in house

09:16

and or by any external parties that

09:20

are using your system.

09:24

It is important that your system acceptance testing

09:26

have a security requirements

09:30

as well as the functionality testing requirements.

09:35

The last control area is a 14.3

09:39

test data.

09:41

This area has won control.

09:45

This control is a 14.3 point one

09:48

protection. All of test data

09:52

test data shall be selected, carefully protected and control.

09:58

It is important that production data is not used as test data.

10:03

Often our test environments do not have the same level of security as the production environments.

10:09

So using your production data in your test environment

10:13

can expose that data to risk.

10:16

There is also the issue of people in your test environment may not necessarily have the appropriate clearance or authorization to view the production data.

10:28

There is also, of course, the privacy concern

10:33

with displaying people's personal information

10:37

when it is not a direct business processing requirement.

10:41

So ensure that you have dummy test data

10:45

and that it is appropriately protected and controlled

10:48

as test data can still give away pertinent information to how the system works and what type of information is being processed and output by the system.

11:05

In this video, we covered the three control areas that make up controls it a 14,

11:11

which is system development, acquisition and maintenance.

11:15

We went through the different controls contained in this control set,

11:18

looked at what these controls mean