A14 System Acquisition, Development and Maintenance
Join over 3 million cybersecurity professionals advancing their career
Sign up with
Required fields are marked with an *
Already have an account? Sign In »
7 hours 52 minutes
a 14 system acquisition, development and maintenance.
In this video, we will understand control. Sit a 14
in relation to your ice mess. We will look at the different control areas as well as the controls that they contain
and go through some examples off evidence that could be requested by your auditor during audits,
Control said. A 14 system development,
my acquisition and maintenance
consists of three control areas.
The first area, a 14.1
security requirements of information systems,
consists of three controls.
These controls are
a 14.1 point one
information security requirements, analysis and specification.
So when you do your business requirements, analysis
and your systems specifications documents,
it is important to ensure that information security related requirements are identified and included in the requirements,
either for these new information systems or where enhancements to existing information systems are being made.
Evidence for this can include the requirements specification documents themselves,
as well as any guidance or procedure documents specifying how to identify security related requirements.
The next control is a 14.1 point two
securing application services on public networks,
so this control pertains to any information that is involved in application services
and which passes over public networks shall be appropriately protected from any fraudulent activity,
or unauthorized disclosure and modification.
So this kind of
entails security in any AP ICE that you are making use off,
ensuring that your application enforces secure transport over https and Tellis protocols,
and so forth.
The last control in the first control area
is a 14.1 point three
protecting application services transactions.
This control pertains to any information that is involved in application service. Transactions
must be appropriately protected to prevent incomplete transmission,
any mis routing,
unauthorized message alteration,
or any unauthorized message, duplication or replay.
you would have evidence involving any policies or procedures pertaining to preventing
and protecting service transactions,
and the disclosure there are.
This would most likely involve the configuration of various controls in your databases
as well as theatric ations transmitting the service transactions.
Your order Thio here would most likely want to see if there have been any areas
how these adult with
and how the system handles
to the ways in which information should be protected.
The second control area
is a 14.2
security in development and support processes.
The first control
is a 14.2 point one
the Secure Development Policy.
This will entail a policy or some document that specifies rules for the development of software and systems
specifically with regards to security,
and that these air applied to developments within the organization.
A 14.2 point two
is your system change control procedures.
This control specifies that all changes to systems within the development life cycle
shall be controlled by the use of formal change control procedures.
This change management procedure may or may not be different from your overall change management procedure,
so be sure that you have either established a separate change management procedures specifically to us Telsey
or, if you leverage off your overall one,
just make it clear when the changes pertain directly to system changes.
The next control is a 14.2 point three
technical review of applications after operating platform changes.
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
that your business critical applications are reviewed and tasted
to make sure that there is no adverse impact as a result of your operating platform changing,
you're orderto will ask to see if there has been any evidence off this occurring during the period under review.
A 14.2 point four
restrictions on changes to software packages.
It's specific to modifications off software packages
on that, these modifications are discouraged, limited to necessary changes
and all changes being strictly controlled.
If your organization has an in house software development team,
you will most likely make use of some sort of code repository.
And these controls will help to enforce the restriction on changes to software packages.
Ensure that any rules around this are formally documented
and that these rules have been appropriately implemented on the software itself.
A 14.2 point five
secure system engineering principles.
This control means that you will basically have a secure systems development life cycle process.
The principles for engineering secure systems shall be established, documented, maintained and applied to any information system implementation efforts,
so this pertains to both in house developed systems as well as any off the shelf
or third party systems used.
It's basically coming down to ensuring that security is built in from as early as possible
in the process as possible
and not built on at a later stage.
A 14.2 point six
secure development environment
here. Your organization needs to establish and appropriately protect your development environment
to ensure that your development environment is kept
and only appropriate and authorized personal. Have access to this environment.
A 14.2 point seven
in any case is where your organization makes use of art. Source.
Your organization needs to supervise and monitor the activity off the outsource system development.
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.
A 14.2 point eight system security testing.
This boils down to the testing off security functionality
in your code, which is either being developed or in a system that you have procured and are implementing.
This needs to be carried out during development
as well as prior to implementation.
It basically boils down to a penetration test off the system
prior to the system being deployed in your network,
a 14.2 point nine system acceptance testing.
This is the acceptance testing program and related criteria
for new information systems upgrades and new versions.
System acceptance testing can be done in house
and or by any external parties that
are using your system.
It is important that your system acceptance testing
have a security requirements
as well as the functionality testing requirements.
The last control area is a 14.3
This area has won control.
This control is a 14.3 point one
protection. All of test data
test data shall be selected, carefully protected and control.
It is important that production data is not used as test data.
Often our test environments do not have the same level of security as the production environments.
So using your production data in your test environment
can expose that data to risk.
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.
There is also, of course, the privacy concern
with displaying people's personal information
when it is not a direct business processing requirement.
So ensure that you have dummy test data
and that it is appropriately protected and controlled
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.
In this video, we covered the three control areas that make up controls it a 14,
which is system development, acquisition and maintenance.
We went through the different controls contained in this control set,
looked at what these controls mean
and also some examples of evidence that could be required during your words.