Best IT Documents.com Blog


Application Fix Suggestions

Posted in Application,Business (600),Security (1500) by Guest on the March 29th, 2010

Create or modify standardized processes or procedures for:

Business requirements
Project Management
eCommerce Services
Web Design (CSS)
Development
Coding
Interdependent transactions
Authentication
Storybook’s
Testing
Use cases
Acceptance processes
Pre-production security scans and remediation

Dependencies should be:

Accurate Asset Management
Accurate IP Control
Reliable Network infrastructure
Governance:
Policies, Standard and Procedures
Business processes
Upstream / Downstream Dependencies:
eCommerce,
Application Development / testing
Data demographics
Interdependent data flows
Development Test Lab environments
Development knowledgebase

Comments Off on Application Fix Suggestions

Asset Management fix suggestions

Leverage asset technologies such as:

WEBM
CIMOM
Asset discovery / management
AV

Assumptions:

Reliable IP Controls
Gold Standard system and releases
ITIL Change controls
ITIL CMDB
Corporate overall governance

http://www.bestitdocuments.com/Assessments.html

 

Comments Off on Asset Management fix suggestions

Patch Management Dependencies

Posted in Compliances (1300),Policies - Standards (600),Security (1500) by Guest on the March 29th, 2010

Technology and Business dependencies:

eCommerce requirements
Business processes
Data Demographics
Data Flows
Application Development / testing
Governance
Policies, procedures, standards
Compliances

Technology dependencies:

Active Directory (policies)
Accurate DNS
Accurate DHCP
Accurate Asset Management
Accurate IP Control
Reliable Network infrastructure

http://www.bestitdocuments.com/Services.html

 

Comments Off on Patch Management Dependencies

RFP Considerations for Acquisitions and Technology Dependencies

Posted in Application,Compliances (1300),Policies - Standards (600) by Guest on the March 29th, 2010

The needs that lead to a consideration of new acquisitions arise from an organization’s day-to-day Business objectives and business operations. Investment and work process analyses articulate these needs and may recommend process changes, procurement of a new system, or both. If procurement of a new system is an option, the organization enters Pre-Systems Acquisition.

Analysis of system needs:

Business objectives, Business, or Enterprise Investment Analysis.

Objective:

Review key Business objectives or business processes (collectively, work processes), changes in the operational environment, and gaps in capability to determine the need for a new system.

Typical Artifacts:

Investment/work process analysis report documenting business environment, work flows, data and. participants, and work environment or threat environment, operations (and description of missing capabilities); plan for an alternatives and other activities to identify and refine potential solutions; initial security risk assessment related to investment analysis report.

Software Security Actions:

Identify and document threats, given the information in the investment/work process analysis report.

Consider how threats may evolve over the life of the system, including potential vulnerabilities in the work processes that could be exploited.

Identify high-priority risks and establish security evaluation criteria to support a high-level assessment of Business objectives and work process alternatives and risk mitigation options as these processes are refined.

Identify organizations that may influence security requirements and processes, and establish points of contact.

Pre-Systems Acquisition

The goal of Pre-Systems Acquisition is to mature a system solution concept to the degree that.

A suitable acquisition strategy can be developed.

Capability need and solution constraints can be adequately expressed in a Request for Proposal (RFP), such that the offerors can scope and estimate the cost and schedule for the necessary work tasks.

The acquirer understands enough about the solution to plan and prepare for supplier monitoring.

The degree of maturation expected in Pre-Systems Acquisition will depend on the complexity of the system to be acquired and the level of technology, cost, and schedule risk deemed acceptable.

Activities performed during Pre-Systems Acquisition include Refine Concepts, Develop and Assess Technology, Create Acquisition Documentation, Prepare for Supplier Selection, Select Supplier, Establish Contract, and Prepare for Supplier Monitoring. These activities are listed below, along with software security actions the acquirer should perform to lay the foundation for secure software development.


Pre-Systems Acquisition activities

Objective:

Analyze and document (a) user demographics and needs, (b) required capabilities, quality, and performance, (c) concepts of operation, maintenance, and evolution, (d) interfaces with other systems and organizations, including interface stability, and (e) concept-related risks.

Typical Artifacts:

Operational, capabilities descriptions, market research and technology assessment, initial integrated architecture description, initial system threat assessment, technology development strategy, systems engineering plan, test and evaluation strategy.

Software Security Actions:

Establish a software security function, led by an experienced software security professional, within the program office. Prepare charter, effort, schedule, and resource requirements.

Continue to identify threats and vulnerabilities in the emerging operational environment and solution space.

Apply security evaluation criteria to concept refinement activities and artifacts.

If COTS or other non-developmental items are identified as part of candidate solutions, research the items’ current and potential security risks.

Document the approach to continuously identify, specify, and manage software security risks throughout the life cycle.

Hold technical interchange meetings with stakeholders to begin developing an understanding of potential software security issues.

Develop and Assess Technology

Objective:

Develop new or unproven hardware and software technologies to an acceptable maturity level for the acquisition.

Typical Artifacts:

Technology readiness assessment, cost analysis, interoperability and supportability assessment, revised integrated architecture description, system threat assessment, SEM, SIM, and test master plan.

Software Security Actions:

Continue security activities identified for Refine Concepts.

Identify software quality attributes, including security, in candidate system architecture descriptions.

Begin to select and define security properties to monitor throughout the life cycle.

Hold technical interchange meetings with stakeholders to specify software-related system-level security requirements.

Ensure these requirements are traceable to verification activities.

Ensure cost analyses consider costs associated with building in and verifying security.

If software technology development has produced prototype or demonstration systems, ensure appropriate plans exist to “productize” the prototype (i.e., to develop robust software for the operational system) and that these plans include security.

Create Acquisition Documentation   

Objective:

Develop strategy and plan for acquisition, considering key cost, schedule, and performance constraints, and risk. Also, develop and secure approval of documents required by law for the type of system to be acquired.

Typical Artifacts:

Acquisition strategy and acquisition plan; documents required for compliance with statutory and regulatory requirements; threshold and objective values for performance, quality, cost, and schedule parameters (for Corporate, these compose the Acquisition Program Baseline); acquisition risk management plan.

Software Security Actions:

Ensure that the acquisition strategy and plan accommodate security activities and resource requirements.

Review compliance with security-related statutory and regulatory requirements.

Define and incorporate security parameters into the Acquisition Program Baseline.

  

Prepare for Supplier Selection.

Objective:

Develop Request for Proposal
(RFP) and supplier selection process.

Typical Artifacts:

RFP, with technical requirements, instructions to offerors, statement of work, requirements for contractual deliverables (management and technical), evaluation criteria, and other conditions related to the proposal; and SSP, identifying organization and responsibilities of the source selection team, evaluation criteria, and detailed procedures for proposal evaluation.

Software Security Actions:

Ensure that the RFP

Requires offerors to apply robust software engineering practices for all software regardless of origin and to demonstrate in the proposal their intent and ability to do so specifies technical and management requirements and standards for software security, expected contractor support for government-led security reviews and audits, and expected government participation in contractor-led security reviews.

Requires delivery and update of a preliminary software/ system security plan covering all offeror’s team members with software responsibility.

Specifies content and delivery schedule and media for software artifacts to be produced during System Acquisition.

Identifies government access required to contractor artifacts and facilities for security reviews requires that the offerors identify and estimate the work tasks and costs associated with interacting with government security organizations throughout the life cycle.

Ensure that the source selection team includes a software security expert who will participate in proposal evaluation to identify strengths, weaknesses, and risks associated with security-related technical and management practices and deliverables and corresponding cost and schedule estimates.

Develop a strategy and plan for evaluating, during supplier selection, the offerors’ ability and intent to meet critical security requirements.

Select Supplier           

Objective:

Select the proposal that represents the best value.

Typical Artifacts: Strengths, deficiencies, significant weaknesses, and risks of each proposal as documented against the evaluation criteria defined in the RFP and per the SSP; clarification requests; cost realism analysis; ability of offerors to meet technical requirements; initial and final proposals; and source selection decision and rationale.

  

Software Security Actions:

Ensure software security expert reviews proposal sections with software security implications.

Before competitive range is established and as needed, prepare security-related clarification requests to be submitted to offerors.

After competitive range is established and if discussions are permitted, prepare for discussions on security deficiencies, weaknesses, or risks related to offerors’ approaches.

  

Establish Contract      

Objective:

Finalize the contract and complete preparation for supplier monitoring.

  

Typical Final contract

Software Security Actions:

Review and approve contractor plans for mitigating security-related weaknesses and risks identified in the winning proposal.

Identify and plan for security-related review activities.

Prepare for Supplier Monitoring        

Objective:

Document plan for supplier monitoring activities along with resource needs (quantity and area of expertise). Identify resources to be used for each activity, artifacts to be produced (e.g., review comments), and plan for approving, using, and archiving these artifacts. Identify and document known risks.

Typical Artifacts: Supplier monitoring plan and updated acquisition risk management plan.

Software Security Actions:

Include in supplier monitoring plan activities for a software security expert to review evolving artifacts and participate in relevant system and software reviews.

Ensure acquisition risk management plan incorporates software security risk.

Define approach to monitor the evolving system and operational context and manage emerging software security risks.

Conduct software kick-off workshop for security (may be included as part of an overall workshop to address quality attributes in a software context).

In defining a framework for government involvement in software security, ensure change control boards have a standing member who is a security specialist and include evaluation of software security implications and risks.

Systems Acquisition

The goal of Systems Acquisition is to design, develop, and deliver an initial system capability. As the contractor team conducts its engineering activities, the acquirer evaluates the progress and outcomes of these activities, including interim artifacts. This is especially critical for large, complex systems in which there are many variables and risks. For a non-functional attribute such as software security, it is particularly important to remain vigilant throughout Systems Acquisition, because changes in requirements, the environment, and cost and schedule constraints can overwhelm efforts related to such “invisible” attributes.

Note:

For some types of systems, especially those with complex hardware development, system-level activities may not correspond directly with software activities. For example, with iterative software development methods, some software items may complete design during early system design, while other software items may not start design until system design is complete.

Activities performed during Systems Acquisition include Monitor System Design; Monitor System Implementation, Integration, and Verification; and Monitor Delivery and Validation of Initial Capability. These activities are listed below, along with software security actions the acquirer should perform to prevent, or identify and mitigate, security issues.

  

Systems Acquisition activities

Monitor System Design         

Activity Description

Objective:

Ensure the design for the system, including all hardware, software, interfaces, and operations and sustainment concepts, is adequate to support implementation.

Typical Artifacts: Evolving software and system artifacts (e.g., architectures, requirements, designs, software, hardware, verification and review records, plans, measures, review presentations, change requests, assurance cases and evidence).

Software Security Actions:

Review/audit software artifacts against security cr
iteria.

Review security-related artifacts, e.g., use and abuse cases, assurance cases, SSP, certification and accreditation plans. Ensure these artifacts are updated and matured as the system evolves.

Conduct biweekly technical interchange meetings during system design to ensure an adequate and sustained focus on security.

Ensure adherence to security plans and modification of plans if necessary.

Continue to identify, manage, and track security risks and issues identified through contractor and government reviews. Identify risks associated with Dependencies between systems.

  

Multiple administrative control points

Operations for individual systems and systems of systems.

Impact of changing system states and operating environment.

Volatility (architecture, requirements, design, code, staff, plans, procedures).

For software developed using iterative approaches, ensure each iteration (increment, build, spiral) includes a security risk evaluation.

Evaluate proposed upgrades and changes to non-developmental items (e.g., COTS and reuse) for continuing suitability with respect to security criteria.

Re-evaluate security artifacts and activities as the operational context, system definition, and threat environment change.

Monitor System Implementation, Integration, and Verification.

Objective:

Implement and integrate the system and verify that it is ready for production (for high-quantity systems) or build activities and integration into the operational environment.

Typical Artifacts: Evolving software and system artifacts (e.g., architectures, requirements, designs, software, hardware, instructions and procedures, verification and review records, certification and accreditation records, assurance cases and evidence, plans, measures, review presentations, change requests).

  

Software Security Actions:

Continue security activities initiated previously.

Monitor changes to system and software artifacts driven by requirements changes, iterative development, and deficiency reports for security impacts.

Review delivery and installation processes for security risks.

Review test plans and test equipment to ensure they will adequately address security requirements, given changes to system and software artifacts.

Review operator, user, and maintenance manuals and associated processes for security risks.

Ensure security-related configuration management and control practices are established and ready for use in the operational environment and maintenance facility, review regression testing procedures, and participate in C&A activities.

  

Monitor Delivery and Validation of Initial Capability          

Objective:

Ensure the system (or first increment of capability) is acceptable for use in the operational environment.

Typical Artifacts: System hardware and software; installation and configuration management procedures and report; acceptance report; verification/validation records; operator, user, and maintenance manuals; system security plan; other deliverable documentation; deficiency reports; C&A report; and assurance cases and evidence.

  

Software Security Actions:

Review artifacts.

Monitor installation process to ensure appropriate configuration of deployed system. Document and resolve security risks and issues.

Monitor initial operations and early defect reports and change requests. Monitor change procedures, if applicable, for security risks and issues.

Ensure security-related configuration management and control practices are applied, and participate in C&A activities.

http://www.bestitdocuments.com/Services.html

Comments Off on RFP Considerations for Acquisitions and Technology Dependencies

List of Suggested Security Awareness Raising Methods

Posted in Business (600),Compliances (1300),Security (1500) by Guest on the March 28th, 2010

The following topics are not organized in priority order; they are instead clustered by the type of communication involved.  Consider this list to be a menu from which appropriate activities may be selected.  The policy writer should not select just one or two of the following methods, but ten or twenty of them.  Repetition of information security policy ideas is essential; repetition impresses users and other audiences with the importance that management places on information security.
 

In-Person
Provide special classroom-style training courses at convenient locations every year or so (for users, systems administrators, remote site information security coordinators, new hires, and other audiences  identified  in a needs analysis.

Deliver policy ideas and other material at new employee orientation. Send influential information systems staff to off-site information security conferences. Hold video conferences where people from various sites discuss security Stage vulnerability demonstrations (aka tiger-team attacks or penetration attacks).
 

Conduct risk assessments, especially when interviewing and other methods are used to engage staff in the Process:

  • Give small prizes like free lunches to exemplary staff
  • Conduct EDP audits, actually checking the extent to which compliance exists
  • Initiate an unauthorized software duplication inventory project where personal computers are checked for  Illegal software
  • Integrate security content with other face-to-face computer training materials
  • Establish and promote the existence of a management information security oversight committee
  • Establish a committee of systems administrators and other first-line staff who must deal with information security
  • Start disciplining staff for violations of information security policies, and let the reasons why disciplinary actions were used be known to others
  • Initiate strategic planning, new product development, and other initiatives which see information and information systems as a key to future competitive advantage
  • Prevent the use of certain new and desired system services (such as Internet access) until certain security projects (like a firewall) have been completed
  • Institute a new or more serious change control approval process, such as the prohibition against the establishment of new phone lines without first getting the information security manager’s approval; with the classic approach, an application does not move into production until adequate controls are installed
  • Declare an amnesty day for information security violators who wish to obtain technical or other assistance so that they may now be in compliance
  • Adopt an annual information security day on which special educational materials are presented and special events take place
  • Initiate a high-profile investigation into an information security breach and engage a large number of staff members in the investigation
  • Schedule special top management briefings where the strategic issues regarding changes in corporate culture to support information security are addressed
  • Conduct an internal survey of mid- and lower-level managers asking them what they think should be done to improve information security (thereby getting them to think about something that they probably don’t think about much)
    In Writing
     

Add information security questions to written performance reviews:

  • Require a signature on personal responsibility statement (indicates that employees consider compliance with policies to be a condition of continued employment)
  • Require a signature on a form verifying that a worker has received a copy of, read, and understood the information security manual
  • Require all employees to annually sign a statement saying they have read and understood the information security policy manual
  • Require users to sign a security compliance statement before they get user-IDs
  • Write security articles for in-house newspapers, newsletters, and magazines
  • Issue written policy statements, procedures, and technical standards
  • Issue pamphlets or brochures to end users describing a code of conduct
  • Issue top management memos reminding staff about security
  • Distribute relevant clippings from newspapers and technical magazines
  • Hang posters and signs to remind people (some also use stickers and decals)
  • Make up special labels for disks, tape reels, etc. indicating sensitivity, handling instructions, ownership, and the like
  • Post notices on both paper and electronic bulletin boards
  • Insert notices in pay-check envelopes, air flight ticket envelopes, etc.
  • Integrate security ideas with systems development process documentation
  • Issue information security responsibility organizational design memos
  • Prepare an information security architecture or otherwise integrate security into the organization’s technology plans
  • Issue an information security manual containing policies, contact persons, and a list of approved in-house products
  • Write detailed back-up instructions and insist that staff comply
  • Develop and test a contingency plan to deal with information
    system emergencies and disasters
  • Require that information security risk acceptance forms be signed by all managers who are in charge of units which are not in compliance and which don’t intend in the near future to come into compliance
  • Prepare non-disclosure agreements and educate staff when they should be used
  • Prepare non-complete agreements and educate staff when they should be used
  • Prepare notices to be given to all people who come into contact with trade secrets notifying them that certain information is a trade secret and that it must be handled according to special security rules (policies)
     

On Systems
Add security instructions to application program and system utility help-screens:

  • Purchase computer based training (CBT) software that runs on personal computers and require staff to go through it; this should ideally automatically reporting back to an information security officer’s PC just how many workers have completed the training
  • Before users gain access to certain applications or systems facilities, force them to first go through a brief on-line training program
  • Prepare a personal computer security utility software disk including encryption routines, a password access control utility, a disk scrub (zeroization) utility, and a self-assessment questionnaire
  • Employ written or automated questionnaires to gauge the (self-assessed) level of compliance
  • Use special software to check security parameters, alerting security staff that problems exist (O/S installed incorrectly, passwords easily guessed, etc.); this is sometimes called vulnerability identification software
  • Set-up an in-house intranet server and post all information security documentation to that server (including forms)
  • Establish web site blocking software at the firewall to control the sites that staff visit and then issue a memo explaining the new system and why it has been adopted
  • Require that all portable personal computers used for corporate business employ an access control software package including a boot password and screen blanker
  • Adopt a commercial encryption product as an in-house standard and internally publicize the ways that this will assist the organization with a move towards implementing PKI (public key infrastructure)
  • Establish logging systems that detect security violations as well as a formal process for (as needed) notifying users and their managers
  • Change the log-on banner to prohibit electronic trespassing, state that the system facilities are for business use only, and that all user activity is subject to monitoring
  • Change the initial invocation banners for specific applications (including e-mail) to provide application-specific security policies and/or other security instructions
  • Install regularly changing on-screen reminders, such as those which show at log-in time
  • Require users to click on a button indicating their agreement to comply with all information security polices at the time they log-in to corporate information systems or networks
  • Place a notice on log-in screens (perhaps at a firewall or dial-up modem pool) that says users should proceed no further unless they have reviewed and understand Corporate’s information security policy
  • Use software agents that remind staff to perform certain security activities such as regularly back-up their systems
  • Give all systems administrators the email address of the Computer Emergency Response Team (CERT) at

o Carnegie-Mellon University and get them to sign-up for free notices about vulnerabilities
 

On Other Things
Write information security messages on coffee mugs, mouse pads, glass coasters, and other trinkets:

  • Prepare video tapes that can be distributed to all remote locations (most often splicing material from previously-prepared videos)
  • Establish a hot-line with a message machine where information security problems can be reported (perhaps anonymously)
  • Cycle awareness materials on kiosks with built-in personal computers, or on closed-circuit TVs in staff-only areas like a lunch-room
Comments Off on List of Suggested Security Awareness Raising Methods

Some storage considerations

 

 

DAS 

NAS 

SAN

 iSCSI

Type of connection • SCSI
• FC-AL
• ….
• Fast Ethernet
• Fibre Channel
• Fibre Channel • Internet
Remote connection • Typically no • Yes • Possible • Yes
Type of I/O • Block  • File  • Block  • Block
Performance • High  • Limited by the network  • Higher  • Limited by the network
Data sharing • Implies NFS or CIFS  • Native  • Difficult  • Difficult
Cost reduction • No  • Yes  • Yes  • Yes
Investment separation • No  • Yes  • Yes  • Yes
Scalability • No  • Yes  • Yes • Depends on network
Centralization of management and support • Typically no  • Yes  • Yes  • Yes
Management • Traditional • SNMP  • Difficult  • Difficult
LAN-Free Backup • No • Depends on NAS  • Yes • Depends on iSCSI
Server-Free Backup • No • Depends on NAS  • Yes • Depends on iSCSI
Security • By the server • By the server • By the servers and storage network • By the servers and network
Installation • Specific to the server • Simple  • Difficult  • Difficult

 

Comments Off on Some storage considerations
Next Page »