Application and Systems Development

2,809 views

Published on

Application and Systems Development

Published in: Technology
0 Comments
2 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
2,809
On SlideShare
0
From Embeds
0
Number of Embeds
64
Actions
Shares
0
Downloads
0
Comments
0
Likes
2
Embeds 0
No embeds

No notes for slide
  • Approach Interaction/Discussion Based upon security general security principles Overlap The topic categories are arbitrary Discussion will touch on the same areas multiple times First topic: Application system development
  • Application and Systems Development

    1. 1. Introduction <ul><li>Topic: Application and System Development </li></ul><ul><li>General security principles </li></ul><ul><li>The Problem </li></ul><ul><li>The Controls </li></ul>
    2. 2. General Security Principles <ul><ul><ul><li>Accountability </li></ul></ul></ul><ul><ul><ul><ul><li>Authorization </li></ul></ul></ul></ul><ul><ul><ul><ul><li>Logging </li></ul></ul></ul></ul><ul><ul><ul><li>Separation of duties </li></ul></ul></ul><ul><ul><ul><li>Least privilege </li></ul></ul></ul><ul><ul><ul><li>Risk reduction </li></ul></ul></ul><ul><ul><ul><li>Layered defense </li></ul></ul></ul>
    3. 3. The Initial Problem <ul><li>Access to Information in a Database </li></ul><ul><ul><li>Release of information </li></ul></ul><ul><ul><li>Modification of information </li></ul></ul><ul><ul><li>Denial of service </li></ul></ul><ul><li>Discretionary vs Mandatory </li></ul><ul><ul><li>Specific authorization granted and denied </li></ul></ul><ul><ul><li>Authorization based on assigned classification </li></ul></ul><ul><li>Relational vs Object Oriented </li></ul>
    4. 4. Relational Database <ul><li>Tables </li></ul><ul><ul><li>“ Relation” (Table or set of columns in table) </li></ul></ul><ul><ul><li>With “Attributes” (Columns) </li></ul></ul><ul><ul><li>Having “Permissible values” </li></ul></ul><ul><ul><li>Specific Attribute is “Key” with unique values </li></ul></ul><ul><ul><li>Occurring in “Instances” (Rows) </li></ul></ul><ul><ul><li>“ Tuple” of a Relation Instance </li></ul></ul><ul><li>Views </li></ul><ul><ul><li>“ Virtual” Relations (tables) </li></ul></ul><ul><ul><li>With selected “Attributes” </li></ul></ul><ul><ul><li>Linked by Key attributes </li></ul></ul>
    5. 5. Relational Database Controls <ul><li>Grant/Revoke Privileges by Table, Column, Key set </li></ul><ul><li>Permissions by View combining specific Tables, Columns, Key sets </li></ul><ul><ul><li>Conceptually dividing the database into pieces to allow sensitive data to be hidden from unauthorized users </li></ul></ul><ul><ul><li>Authorizations for specific views having specific attributes, and for actions to perform within those views </li></ul></ul><ul><ul><li>DAC, by specific grant to user or group by owner </li></ul></ul><ul><ul><li>MAC, by classification level </li></ul></ul><ul><li>“ Granularity” - fineness of control permissible in database controls - dependent upon database and implementation </li></ul>
    6. 6. Relational Database Issues <ul><li>Issues: </li></ul><ul><ul><li>Verifying access granted - DAC </li></ul></ul><ul><ul><li>Verifying that View limitations function - MAC </li></ul></ul><ul><ul><li>Preventing users from creating a copy (becoming “owner”) and granting access to others </li></ul></ul>
    7. 7. Object-Oriented Database <ul><li>“ Subjects” </li></ul><ul><li>“ Objects” </li></ul><ul><li>“ Methods” of accessing them </li></ul><ul><li>Controls using Encapsulation, Inheritance, Information hiding </li></ul><ul><li>“ Granularity” - fineness of control permissible in database controls </li></ul>
    8. 8. DAC Object-Oriented Models <ul><li>ORION - Explicit authorization for groups of users to objects based on role </li></ul><ul><li>Data Hiding (Dr. Elisa Bertino) - Explicit authorization for (groups of) users to objects using “public methods” </li></ul><ul><li>Control of Function Evaluations (Rafiul Ahad) - Explicit authorization for (groups of) users to execute specific methods </li></ul><ul><li>Methods Data Hiding (Joel Richardson) - Explicit authorization to execute specific methods determined by the owner </li></ul>
    9. 9. DAC Object-Oriented Models - 2 <ul><li>Positive/Negative Authorizations (Dr Eduardo Fernandez) - Explicit positive and negative authorizations </li></ul><ul><li>View Mechanism (Dr Naftaly Minsky) - Multiple interfaces to objects with a list of laws (rules) governing access </li></ul>
    10. 10. MAC Object-Oriented Models <ul><li>SORION (Dr Bhavani Thuraisingham) - Assigns security/sensitivity levels to subjects, objects and access methods and regulates access via “properties” based on sensitivity levels </li></ul><ul><li>Millen-Lunt Model - Assigns sensitivity levels to subjects, objects and access methods and regulates access via axioms and three cases: </li></ul><ul><ul><li>Data is classified </li></ul></ul><ul><ul><li>Existence of data is classified </li></ul></ul><ul><ul><li>Reason for classifying data is classified </li></ul></ul><ul><li>SODA (Dr Thomas Keefe) - Secure Object-Oriented Database </li></ul><ul><ul><li>Presented as a standard example </li></ul></ul><ul><ul><li>Assigns classification levels via inheritance </li></ul></ul>
    11. 11. Object-Oriented Issues <ul><li>ISSUES </li></ul><ul><ul><li>Polyinstantiation </li></ul></ul><ul><ul><ul><li>Producing a more defined version of an object by iteratively replacing variables with other variables or values </li></ul></ul></ul><ul><ul><ul><li>Information located in more than one location for use by more than one user, usually having different security levels </li></ul></ul></ul><ul><ul><ul><li>Requires sensitive information to be removed when stored at lower levels </li></ul></ul></ul><ul><ul><ul><li>Insuring integrity with multiple updates going on is difficult </li></ul></ul></ul><ul><ul><li>Polymorphism </li></ul></ul><ul><ul><ul><li>Different objects responding to a common command in different ways </li></ul></ul></ul>
    12. 12. Programming/Data Attacks <ul><li>Salami attack </li></ul><ul><li>Data diddling </li></ul><ul><li>Fraud </li></ul><ul><li>Logic bomb </li></ul><ul><li>Mistakes </li></ul><ul><li>Boundary errors </li></ul><ul><li>Validation errors </li></ul><ul><li>Time of Check/Time of Use (serialization) errors </li></ul><ul><li>Covert channels </li></ul>
    13. 13. Database Controls <ul><li>Biggest issue still mistakes, omissions </li></ul><ul><li>Protection by operating system/platform/db </li></ul><ul><ul><li>Physical data base integrity </li></ul></ul><ul><ul><li>Logical data base integrity </li></ul></ul><ul><ul><li>Element integrity </li></ul></ul><ul><ul><li>Auditability </li></ul></ul><ul><ul><li>Access control </li></ul></ul><ul><ul><li>User authentication </li></ul></ul><ul><ul><li>Availability </li></ul></ul><ul><li>Two-phase update (Intent/Commit and Lock) </li></ul><ul><li>Error detection/correction </li></ul><ul><li>Integrity with multiple instances (polyinstantiation) </li></ul>
    14. 14. Applications Beyond the Database <ul><li>Centralized systems </li></ul><ul><ul><li>Biggest issue still mistakes, omissions </li></ul></ul><ul><ul><li>Protection by operating system/platform </li></ul></ul><ul><ul><ul><li>Physical data base integrity </li></ul></ul></ul><ul><ul><ul><li>Logical data base integrity </li></ul></ul></ul><ul><ul><ul><li>Element integrity </li></ul></ul></ul><ul><ul><li>Database and controlled access links </li></ul></ul><ul><ul><li>Layers of vulnerabilities </li></ul></ul><ul><ul><li>Examples and Vulnerabilities </li></ul></ul>
    15. 15. Applications Beyond the Database <ul><li>Centralized systems </li></ul><ul><li>Distributed systems </li></ul><ul><ul><li>More normal now </li></ul></ul><ul><ul><li>“ Decentralized” - connected or unconnected but related platforms running independent copies of software with independent copies of data </li></ul></ul>
    16. 16. Applications Beyond the Database <ul><li>Centralized systems </li></ul><ul><li>Distributed systems </li></ul><ul><ul><li>“ Decentralized” - connected or unconnected but related platforms running independent copies of software with independent copies of data </li></ul></ul><ul><ul><li>“ Dispersed” - interconnected and related platforms running the same software and using the same data, one of which (data or software) is centralized </li></ul></ul><ul><ul><li>Accommodates change </li></ul></ul><ul><ul><ul><ul><li>Deploys resources </li></ul></ul></ul></ul><ul><ul><ul><ul><li>Improves performance </li></ul></ul></ul></ul><ul><ul><ul><ul><li>Lower risk of system failure due to hardware malfunction </li></ul></ul></ul></ul>
    17. 17. Applications Beyond the Database <ul><li>Centralized systems </li></ul><ul><li>Distributed systems </li></ul><ul><ul><li>“ Decentralized” - connected or unconnected but related platforms running independent copies of software with independent copies of data </li></ul></ul><ul><ul><li>“ Dispersed” - interconnected and related platforms running the same software and using the same data, one of which (data or software) is centralized </li></ul></ul><ul><ul><li>“ Interoperable” or “Cooperative” - interconnected platforms running independent copies of software with independent copies of data </li></ul></ul><ul><ul><li>Combines processing from dissimilar platforms </li></ul></ul><ul><ul><ul><ul><li>Independently execute/test each component </li></ul></ul></ul></ul>
    18. 18. Definitions <ul><li>Loose coupling </li></ul><ul><ul><li>weak dependencies between modules </li></ul></ul><ul><li>High cohesion </li></ul><ul><ul><li>modules perform discrete functions </li></ul></ul><ul><li>Together, design supporting distributed systems </li></ul><ul><li>Agent </li></ul><ul><ul><li>Client/server local link to other areas of system, performs information preparation & exchange for client or server </li></ul></ul>
    19. 19. Potential Vulnerabilities <ul><li>Data problems </li></ul><ul><ul><li>Aggregation - building new objects from existing objects </li></ul></ul><ul><ul><li>Inference deriving information not explicit </li></ul></ul><ul><ul><li>Object reuse/garbage collection - reclaiming information from dynamic storage </li></ul></ul><ul><ul><li>Data contamination </li></ul></ul>
    20. 20. Potential Vulnerabilities <ul><li>Malicious Code </li></ul><ul><ul><li>Trojan horse - program with hidden and undesirable functions </li></ul></ul><ul><ul><li>Virus - malicious, usually destructive, code that infects other programs to propagate itself </li></ul></ul><ul><ul><li>Logic bomb - hidden code designed to perform undesirable activities upon receiving or observing a specific condition </li></ul></ul><ul><ul><li>Letter bomb - email attachment with malicious code </li></ul></ul><ul><ul><li>Worm - a program that uses communications methods to propagate itself between systems </li></ul></ul><ul><ul><li>Applet - platform-independent download-and-run mini-program used in Java programming </li></ul></ul>
    21. 21. Other Definitions <ul><li>Java </li></ul><ul><ul><li>Sun “platform-independent” programming language </li></ul></ul><ul><ul><li>Object-oriented, distributed, interpreted </li></ul></ul><ul><li>ActiveX </li></ul><ul><ul><li>Microsoft replacement for Java - stripped OLE, designed to run on slow Internet links </li></ul></ul>
    22. 22. Potential Vulnerabilities <ul><li>Access problems </li></ul><ul><ul><li>Trap door - secret way in </li></ul></ul><ul><ul><li>Back door - unapproved method of accessing the system </li></ul></ul><ul><ul><li>Covert channel - Unapproved communications link between application and another </li></ul></ul><ul><ul><ul><li>Covert storage channel - Writing to storage through one process, and reading by another (lower security level) </li></ul></ul></ul><ul><ul><ul><li>Covert timing channel - Processes signal to one another by modulating system use </li></ul></ul></ul><ul><ul><li>Physical access to the area </li></ul></ul>
    23. 23. Vulnerabilities Summary <ul><li>Spoofing/Eavesdropping </li></ul><ul><li>Unable to identify/track access/updates </li></ul><ul><li>Theft of information or hard assets </li></ul><ul><li>Improper access to information </li></ul><ul><li>Improper update of information </li></ul><ul><li>Improper destruction of information </li></ul><ul><li>Lack of or inadequate data validation </li></ul><ul><li>Data overwrites </li></ul><ul><li>Incorrect internal processing </li></ul><ul><li>Direct data access </li></ul>
    24. 24. Definitions <ul><li>Data mining </li></ul><ul><ul><li>Analyzing databases for trends/anomalies using automated tools without knowledge of data </li></ul></ul><ul><li>Knowledge-base system </li></ul><ul><ul><li>System to query a collection of knowledge expressed using a formal knowledge representation language </li></ul></ul><ul><li>Artificial Neural Network </li></ul><ul><ul><li>Simple processors networked on a uni-directional communications channel that operate on local data and input from the connection </li></ul></ul><ul><ul><li>able to learn from example and to generalize </li></ul></ul>
    25. 25. Definitions <ul><li>OLE </li></ul><ul><ul><li>MS Object Linking & Embedding </li></ul></ul><ul><li>CORBA </li></ul><ul><ul><li>Common Object Request Broker Architecture (Object Management Group) </li></ul></ul><ul><li>Structured Programming </li></ul><ul><ul><li>Using programming rules and procedures and pre-programmed modules </li></ul></ul>
    26. 26. Controls - Personnel Issues <ul><li>Accountability and Risk Reduction </li></ul><ul><ul><li>Background checks of all personnel </li></ul></ul><ul><li>Separation of Duties </li></ul><ul><ul><li>Separate responsibilities for application development, approval, implementation, support </li></ul></ul>
    27. 27. Application System Development <ul><li>Implement a Systems Development Life Cycle </li></ul><ul><ul><li>Quality Assurance program </li></ul></ul><ul><ul><li>Involve QA/QC, Audit, Information Security </li></ul></ul><ul><ul><li>Enforce review and approval of all applications </li></ul></ul>
    28. 28. Application System Development <ul><li>Systems Development Life Cycle </li></ul><ul><ul><li>Applies to new development AND system maintenance </li></ul></ul>
    29. 29. Application System Development <ul><li>Systems Development Life Cycle </li></ul><ul><ul><li>Applies to new development AND system maintenance </li></ul></ul><ul><ul><li>Include infosec reviews at each milepost of cycle </li></ul></ul><ul><ul><ul><li>Verify that security requirements have been met </li></ul></ul></ul><ul><ul><ul><li>Perform review of design and code </li></ul></ul></ul>
    30. 30. Application System Development <ul><li>Systems Development Life Cycle </li></ul><ul><ul><li>Applies to new development AND system maintenance </li></ul></ul><ul><ul><li>Include infosec reviews at each milepost of cycle </li></ul></ul><ul><ul><li>Project Initiation </li></ul></ul><ul><ul><ul><li>Involve information security in initial discussion of project </li></ul></ul></ul><ul><ul><ul><li>Perform Risk Assessment to </li></ul></ul></ul><ul><ul><ul><ul><li>Define sensitivity of information </li></ul></ul></ul></ul><ul><ul><ul><ul><li>Define criticality of system </li></ul></ul></ul></ul><ul><ul><ul><ul><li>Define security risks </li></ul></ul></ul></ul><ul><ul><ul><ul><li>Define level of protection needed </li></ul></ul></ul></ul><ul><ul><ul><ul><li>Ensure regulatory/legal/privacy issues are addressed </li></ul></ul></ul></ul><ul><ul><ul><li>Ensure requirements can be met by application </li></ul></ul></ul>
    31. 31. Application System Development <ul><li>Systems Development Life Cycle </li></ul><ul><ul><li>Applies to new development AND system maintenance </li></ul></ul><ul><ul><li>Include infosec reviews at each milepost of cycle </li></ul></ul><ul><ul><ul><li>Project Initiation </li></ul></ul></ul><ul><ul><li>Project Definition (Design Analysis) </li></ul></ul><ul><ul><ul><li>Functional/system design requirements </li></ul></ul></ul><ul><ul><ul><li>Determine acceptable level of risk </li></ul></ul></ul><ul><ul><ul><ul><li>Level of loss </li></ul></ul></ul></ul><ul><ul><ul><ul><li>Percentage of loss </li></ul></ul></ul></ul><ul><ul><ul><ul><li>Permissible variance </li></ul></ul></ul></ul><ul><ul><ul><li>Identify security requirements and controls </li></ul></ul></ul><ul><ul><ul><ul><li>Determine exposure points in process </li></ul></ul></ul></ul><ul><ul><ul><ul><li>Define controls to mitigate exposure </li></ul></ul></ul></ul><ul><ul><ul><li>Ensure requirements can be met by application </li></ul></ul></ul>
    32. 32. Application System Development <ul><li>Systems Development Life Cycle </li></ul><ul><ul><li>Applies to new development AND system maintenance </li></ul></ul><ul><ul><li>Include infosec reviews at each milepost of cycle </li></ul></ul><ul><ul><ul><li>Project Initiation </li></ul></ul></ul><ul><ul><ul><li>Project Definition (Design Analysis) </li></ul></ul></ul><ul><ul><li>System Design (Design Specification) </li></ul></ul><ul><ul><ul><li>Detailed planning of functional components </li></ul></ul></ul><ul><ul><ul><li>Design program controls </li></ul></ul></ul><ul><ul><ul><li>Design security mechanisms </li></ul></ul></ul><ul><ul><ul><li>Design test plan </li></ul></ul></ul><ul><ul><ul><li>Design verification </li></ul></ul></ul><ul><ul><ul><ul><li>Mathematical verification of model and design correspondence </li></ul></ul></ul></ul>
    33. 33. Application System Development <ul><li>Systems Development Life Cycle </li></ul><ul><ul><li>Applies to new development AND system maintenance </li></ul></ul><ul><ul><li>Include infosec reviews at each milepost of cycle </li></ul></ul><ul><ul><ul><li>Project Initiation </li></ul></ul></ul><ul><ul><ul><li>Project Definition (Design Analysis) </li></ul></ul></ul><ul><ul><ul><li>System Design (Design Specification) </li></ul></ul></ul><ul><ul><li>Programming/Training (Software Development) </li></ul></ul><ul><ul><ul><li>Development personnel should be authorized to work on system </li></ul></ul></ul><ul><ul><ul><li>Document security </li></ul></ul></ul><ul><ul><ul><li>Training of support personnel and users </li></ul></ul></ul>
    34. 34. Application System Development <ul><li>Systems Development Life Cycle </li></ul><ul><ul><li>Applies to new development AND system maintenance </li></ul></ul><ul><ul><li>Include infosec reviews at each milepost of cycle </li></ul></ul><ul><ul><ul><li>Project Initiation </li></ul></ul></ul><ul><ul><ul><li>Project Definition (Design Analysis) </li></ul></ul></ul><ul><ul><ul><li>System Design (Design Specification) </li></ul></ul></ul><ul><ul><ul><li>Programming and Training (Software Development) </li></ul></ul></ul><ul><ul><li>Installation, Evaluation and Testing </li></ul></ul><ul><ul><ul><li>Development staff should not conduct evaluation/testing </li></ul></ul></ul><ul><ul><ul><li>Certification of security functionality </li></ul></ul></ul><ul><ul><ul><li>Certification of processing integrity </li></ul></ul></ul><ul><ul><ul><li>Desk check, operational test </li></ul></ul></ul>
    35. 35. Definitions <ul><li>Acceptance </li></ul><ul><ul><li>Verification that performance and security requirements have been met </li></ul></ul><ul><li>Accreditation </li></ul><ul><ul><li>Formal acceptance of security adequacy, authorization for operation and acceptance of existing risk (QC) </li></ul></ul><ul><li>Certification </li></ul><ul><ul><li>Formal testing of security safeguards </li></ul></ul><ul><li>Operational assurance </li></ul><ul><ul><li>Verification that a system is operating according to its security requirements </li></ul></ul><ul><li>Assurance </li></ul><ul><ul><li>Degree of confidence that the implemented security measures work as intended </li></ul></ul>
    36. 36. Application System Development <ul><li>Systems Development Life Cycle </li></ul><ul><ul><li>Applies to new development AND system maintenance </li></ul></ul><ul><ul><li>Include infosec reviews at each milepost of cycle </li></ul></ul><ul><ul><ul><li>Project Initiation </li></ul></ul></ul><ul><ul><ul><li>Project Definition (Design Analysis) </li></ul></ul></ul><ul><ul><ul><li>System Design (Design Specification) </li></ul></ul></ul><ul><ul><ul><li>Programming and Training (Software Development) </li></ul></ul></ul><ul><ul><ul><li>Installation, Evaluation and Testing </li></ul></ul></ul><ul><ul><li>Destruction </li></ul></ul>
    37. 37. The Real World <ul><li>Systems Development Life Cycle </li></ul><ul><ul><li>Organizations understaffed, wear too many hats </li></ul></ul><ul><ul><li>Separation of duties seldom complete </li></ul></ul><ul><ul><li>Infosec seldom involved in initial stages of development </li></ul></ul><ul><ul><li>Risks seldom adequately assessed </li></ul></ul><ul><ul><li>Exposure points and controls seldom adequately determined </li></ul></ul><ul><ul><li>Code checks are often skimped </li></ul></ul><ul><ul><ul><li>Approvals are often perfunctory </li></ul></ul></ul><ul><ul><ul><li>Development process continues without formal approval </li></ul></ul></ul><ul><ul><li>Few limits on access to program code </li></ul></ul><ul><ul><li>Change control for programs only </li></ul></ul>
    38. 38. Operational Issues <ul><li>Implementation and Operation </li></ul><ul><ul><li>Code issues - Change Control </li></ul></ul><ul><ul><li>Data issues </li></ul></ul><ul><ul><ul><li>Access </li></ul></ul></ul><ul><ul><ul><li>Integrity </li></ul></ul></ul><ul><ul><li>Personnel issues </li></ul></ul>
    39. 39. Controls <ul><li>Implementation and Operation </li></ul><ul><ul><li>Authorization - </li></ul></ul><ul><ul><ul><li>All support personnel should be authorized </li></ul></ul></ul>
    40. 40. Controls <ul><li>Implementation and Operation </li></ul><ul><ul><ul><li>All support personnel should be authorized </li></ul></ul></ul><ul><ul><li>Risk Reduction - </li></ul></ul><ul><ul><ul><li>All code should be reviewed prior to implementation - Change Management </li></ul></ul></ul>
    41. 41. Controls <ul><li>Implementation and Operation </li></ul><ul><ul><li>All support personnel should be authorized </li></ul></ul><ul><ul><li>All code should be reviewed prior to implementation </li></ul></ul><ul><ul><li>Separation of Duties - </li></ul></ul><ul><ul><ul><li>Development staff should not review, implement systems </li></ul></ul></ul>
    42. 42. Controls <ul><li>Implementation and Operation </li></ul><ul><ul><li>All support personnel should be authorized </li></ul></ul><ul><ul><li>All code should be reviewed prior to implementation </li></ul></ul><ul><ul><li>Separation of Duties - </li></ul></ul><ul><ul><ul><li>Development staff should not review, implement systems </li></ul></ul></ul><ul><ul><ul><li>Development staff should not support production data </li></ul></ul></ul>
    43. 43. Controls <ul><li>Implementation and Operation </li></ul><ul><ul><li>All support personnel should be authorized </li></ul></ul><ul><ul><li>All code should be reviewed prior to implementation </li></ul></ul><ul><ul><li>Separation of Duties - </li></ul></ul><ul><ul><ul><li>Development staff should not review, implement systems </li></ul></ul></ul><ul><ul><ul><li>Development staff should not support production data </li></ul></ul></ul><ul><ul><ul><li>Development staff should not manage security function </li></ul></ul></ul>
    44. 44. Controls <ul><li>Implementation and Operation </li></ul><ul><ul><li>All support personnel should be authorized </li></ul></ul><ul><ul><li>All code should be reviewed prior to implementation </li></ul></ul><ul><ul><li>Development staff should not review, implement systems </li></ul></ul><ul><ul><li>Development staff should not support production data </li></ul></ul><ul><ul><li>Development staff should not manage security function </li></ul></ul><ul><ul><li>Accountability - </li></ul></ul><ul><ul><ul><li>Production data should be managed through programs </li></ul></ul></ul><ul><ul><ul><ul><li>No access should be permitted directly to database </li></ul></ul></ul></ul>
    45. 45. Controls <ul><li>Implementation and Operation </li></ul><ul><ul><li>All support personnel should be authorized </li></ul></ul><ul><ul><li>All code should be reviewed prior to implementation </li></ul></ul><ul><ul><li>Development staff should not review, implement systems </li></ul></ul><ul><ul><li>Development staff should not support production data </li></ul></ul><ul><ul><li>Development staff should not manage security function </li></ul></ul><ul><ul><li>Accountability - </li></ul></ul><ul><ul><ul><li>No access should be permitted directly to database </li></ul></ul></ul><ul><ul><ul><li>Production data should be managed by users, not support staff </li></ul></ul></ul>
    46. 46. Controls <ul><li>Implementation and Operation </li></ul><ul><ul><li>All support personnel should be authorized </li></ul></ul><ul><ul><li>All code should be reviewed prior to implementation </li></ul></ul><ul><ul><li>Development staff should not review, implement systems </li></ul></ul><ul><ul><li>Development staff should not support production data </li></ul></ul><ul><ul><li>Development staff should not manage security function </li></ul></ul><ul><ul><li>Accountability - </li></ul></ul><ul><ul><ul><li>No access should be permitted directly to database </li></ul></ul></ul><ul><ul><ul><li>Production data should be managed by users, not support staff </li></ul></ul></ul><ul><ul><ul><li>All access to production data should be logged </li></ul></ul></ul>
    47. 47. Controls <ul><li>Implementation and Operation </li></ul><ul><ul><li>All support personnel should be authorized </li></ul></ul><ul><ul><li>All code should be reviewed prior to implementation </li></ul></ul><ul><ul><li>Development staff should not review, implement systems </li></ul></ul><ul><ul><li>Development staff should not support production data </li></ul></ul><ul><ul><li>Development staff should not manage security function </li></ul></ul><ul><ul><li>No access should be permitted directly to database </li></ul></ul><ul><ul><li>Production data should be managed by users, not support staff </li></ul></ul><ul><ul><li>All access to production data should be logged </li></ul></ul><ul><ul><li>Least Privilege </li></ul></ul><ul><ul><ul><li>Access control </li></ul></ul></ul><ul><ul><ul><li>Access should be given to necessary data fields only </li></ul></ul></ul>
    48. 48. Controls <ul><li>Implementation and Operation </li></ul><ul><ul><li>All support personnel should be authorized </li></ul></ul><ul><ul><li>All code should be reviewed prior to implementation </li></ul></ul><ul><ul><li>Development staff should not review, implement systems </li></ul></ul><ul><ul><li>Development staff should not support production data </li></ul></ul><ul><ul><li>Development staff should not manage security function </li></ul></ul><ul><ul><li>No access should be permitted directly to database </li></ul></ul><ul><ul><li>Production data should be managed by users, not support staff </li></ul></ul><ul><ul><li>All access to production data should be logged </li></ul></ul><ul><ul><li>Access should be given to necessary data fields only </li></ul></ul><ul><ul><li>Layered Defense </li></ul></ul><ul><ul><ul><li>Access controls should be used in addition to system access </li></ul></ul></ul>
    49. 49. Controls <ul><li>Implementation and Operation </li></ul><ul><ul><li>All support personnel should be authorized </li></ul></ul><ul><ul><li>All code should be reviewed prior to implementation </li></ul></ul><ul><ul><li>Development staff should not review, implement systems </li></ul></ul><ul><ul><li>Development staff should not support production data </li></ul></ul><ul><ul><li>Development staff should not manage security function </li></ul></ul><ul><ul><li>No access should be permitted directly to database </li></ul></ul><ul><ul><li>Production data should be managed by users, not support staff </li></ul></ul><ul><ul><li>All access to production data should be logged </li></ul></ul><ul><ul><li>Access should be given to necessary data fields only </li></ul></ul><ul><ul><li>Access controls should be used in addition to system access </li></ul></ul><ul><ul><li>Configuration Management </li></ul></ul>
    50. 50. The Real World <ul><li>Implementation and Operation </li></ul><ul><ul><li>Organizations understaffed, wear too many hats </li></ul></ul><ul><ul><li>Separation of duties seldom complete </li></ul></ul><ul><ul><li>Development staff often support production systems </li></ul></ul><ul><ul><li>IT staff often maintain production data </li></ul></ul><ul><ul><li>Access is often granted on basis of “least effort” </li></ul></ul>
    51. 51. An Example: Y2K Remediation <ul><li>Y2K remediation being done off site </li></ul><ul><ul><li>3rd party? </li></ul></ul><ul><ul><li>Overseas? </li></ul></ul><ul><ul><li>Background checks? </li></ul></ul>
    52. 52. An Example: Y2K Remediation <ul><li>Y2K remediation being done off site </li></ul><ul><li>Code returned </li></ul><ul><ul><li>Reviewed by qualified staff? </li></ul></ul><ul><ul><li>Gartner estimates at least one $Billion loss due to illicit code in Y2K fixes </li></ul></ul>
    53. 53. An Example: Y2K Remediation <ul><li>Y2K remediation being done off site </li></ul><ul><li>Code returned </li></ul><ul><li>Data corrections being performed by IT remediation staff </li></ul>
    54. 54. Definitions <ul><li>Loose coupling </li></ul><ul><ul><li>weak dependencies between modules </li></ul></ul><ul><li>High cohesion </li></ul><ul><ul><li>modules perform discrete functions </li></ul></ul><ul><li>Due Care </li></ul><ul><ul><li>minimum and customary practice of responsible protection of assets that reflects a community or societal norm </li></ul></ul><ul><li>Due Diligence </li></ul><ul><ul><li>prudent management and execution of due care </li></ul></ul>
    55. 55. Final Considerations <ul><li>What does the development life cycle and change control implementation cover? </li></ul><ul><ul><li>Applications programs? </li></ul></ul><ul><ul><li>Supporting libraries? </li></ul></ul><ul><ul><li>Operating systems? </li></ul></ul><ul><li>Proportionality </li></ul>

    ×