IT SECURITY Power Point Presentation A slide deck that is seven to eight slides
ID: 669409 • Letter: I
Question
IT SECURITY
Power Point Presentation
A slide deck that is seven to eight slides long not including an introduction and summary slide. The purpose of the deck is to provide a presentation to stakeholders describing the many processes you have put in place to ensure secure software development takes place at your organization.
You should discuss software development security by mentioning the following:
Input validation
Database Security
Various code testing frameworks
Secure maintenance of applications
Define software development security tools
Explanation / Answer
1)GENERAL SECURITY PRINCIPLES:
>Authentication
--Who a user is
>Authorization
--What a user can do
>Confidentiality
--What a user can see
>Non-repudiation
--Did a user really perform an action
>Availability
--The system is ready for user activity
2)
SECURITY IN DEVELOPMENT CYCLE:
>Security Analysis in Development is a Risk Mitigation Strategy
--You will not find all the bugs…
--You will not see all the vulnerabilities…
--Your design will have errors of omission and oversight
3)
SECURITY MODELING:
>Define threats
--Consider the data stored in the system, and how it can be misused
--Consider the architecture of the system, and the opportunities it affords malicious users
>Assess the Impact
--You’ve found a vulnerability… what happens if someone actually finds it? How badly would you or your users be affected?
>Implement a Countermeasure
--Mitigate the risk to the best of your ability – code a preventative action, limit the exposure
4)
UNVALIDATED INPUT:
--Client provided data is not properly validated for boundaries, format, etc.
>Approaches:
--Validate inputs before allowing business processing
--Do not rely on client-side validation
--Ensure correct error handling
5)
INJECTION FLAWS:
--A variant of unvalidated input: a script takes request parameters and uses them directly to construct a command passed to another process
--Typically realized as SQL Injection – parameters such as column names or where clause fragments are explicitly used in statement construction
6)
>Apply threat modeling to the application development cycle
>During requirements and design, understand the risks and threats
--Use a method to evaluate the impact and prioritize; ideally looking at each vulnerability against each asset/threat
--Identify critical transactions and risks
--Know the countermeasures
--Awareness leads to coding practices that eliminate most vulnerabilities – e.g., unvalidated input or code-injection flaws.
INPUT VALIDATION:
>Input Validation is the outer defensive perimeter for your web application. This perimeter protects the core business logic, processing and output generation.
>Two main approaches exist for input validation called whitelisting and blacklisting respectively.
>A whitelist will allow you to define what data should be accepted by your application for a given input point, in short you define a set of “known good inputs”.
>The blacklist approach will attempt to do the opposite by defining a set of “known bad inputs” which requires the developer to understand a wide range of potentially malicious inputs.
Input validation practices:
1.Apply whitelists (known good values) where possible
2.Canonicalise all inputs. This means reducing the data received to its simplest form, if the validation functions only searches for UTF-8 input an attacker could use another encoding method, like UTF-16, to encode the malicious characters and bypass the validation function.
3.Check for content (i.e. 0-9), minimum and maximum lengths and correct syntax of all inputs.
DATABASE SECURITY:
>All organizations|public, governmental or private, small or large|depend on computerized infor- mation systems for carrying out their daily activity. At the heart of each such information system, there is a database. At a very general level, we can de ne a database as a persistent collection of related data, where data are facts that have an implicit meaning. For instance, an employee's name, social security number, or date of birth are all facts that can be recorded in a database. Typically, a database is built to store logically interrelated data representing some aspects of the real world, which must be collected, processed, and made accessible to a given user population. The database is constructed according to a data model which de nes the way in which data and interrelationships between them can be represented. The collection of software programs that pro- vide the functionalities for de ning, maintaining, and accessing data stored in a database is called a database management system (DBMS).
>Protection level:
A DBMS usually needs to protect data at a ne granularity level.while an operating system protects data at the le level.
>Data interrelationships:
A database may include many logical objects with complex semantic interrelationships that must be protected. By contrast, the number of physical objects that the operating system protects is less and no semantic interrelationships are supported
>Lifetime of data:
The lifetime and frequency of access of data in a DBMS is quite di erent than the lifetime of data stored as les in an operating system.
Related Questions
drjack9650@gmail.com
Navigate
Integrity-first tutoring: explanations and feedback only — we do not complete graded work. Learn more.