Date: Thu, 28 Mar 2024 17:54:22 +0000 (UTC) Message-ID: <9676911.6742.1711648462095@ip-10-10-7-29.ec2.internal> Subject: Exported From Confluence MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_Part_6741_2110089369.1711648462094" ------=_Part_6741_2110089369.1711648462094 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Location: file:///C:/exported.html
Security risks and events occur throughout a system=E2=80=99s lifetime. = This is true whether the system is developed internally or purchased for on= premise hosting or cloud implementation. Security should be embedded throu= ghout all phases of the system development life cycle, assessed during syst= em acquisition processes, and monitored during system maintenance, includin= g disposal.
System Development=E2=80=93For systems developed by the inst= itution:
Investigate and review how your = institution manages software development for release to the campus communit= y.
Revise the process to ensure the security team is i= nvolved at key points in your institution=E2=80=99s software development li= fe cycle (SDLC). Having security =E2=80=9Cat the table=E2=80=9D early and t= hroughout the SDLC ensures that security requirements are designed, tested = and implemented when they are the least costly. It is particularly critical= to be involved in defining security requirements at the beginning of a dev= elopment project and prior to implementation to validate security requireme= nts are met.
Review Microsoft=E2=80=99s <= span style=3D"color: rgb(0,0,255);text-decoration: underline;">Security Dev= elopment Lifecycle that parallels the system development l= ifecycle and can be used to assist in developing the role of security in ea= ch of the SDLC phases.
System Acquisition=E2=80=93For systems purchased by the inst= itution:
Investigate and review how your institution a= cquires new software. Understand the procurement processes in place when se= lecting vendors; particularly for cloud services.
Determine whether processes encourage proper = assessment of vendor relationships and cloud environments befo= re contracting. For example, Northwestern University has a cle= arly defined process for assessing vendors=E2=80=93Service Provider Security Assessment.
Verify that processes include acceptance crit= eria which will give assurances that security requirements are met.<= /p>
Review and evaluate previous= vendor contractual agreements for security protections. Helpful documents:=
Data Protection Contractual Language= contains sample contractual language for contracts.
= li>Legal and Quasi-Legal Issues in Cloud Computing Contracts= contains information that may be useful in specifying sec= urity requirements.
Develop a plan, if needed, for improving the = contracting process with campus procurement and/or other stakeholders.
See Supplier Relationships
System Maintenance=E2=80=93For systems maintained by the ins= titution:
Top of page=
To be most effective, information security must be integrated into the s= ystem lifecycle from system inception through system disposal. Regardless o= f the formal or informal lifecycle methodology employed, security can be in= corporated into information systems acquisition, development and maintenanc= e by implementing effective security practices in the following areas.
Information systems security begins with incorporating security into the= requirements process for any new application or system en= hancement whether that application is purchased from a vendor or internally= developed. Designing security requirements in systems is most effective at= the early stages of system development. Similarly, security requirements a= re presented to the vendor during the requirements phase of a product or cl= oud service purchase. Formal testing should be done to determine whether th= e product meets the required security specifications prior to purchasing th= e product or moving the application to production.
Security in development and support processes is an ess= ential part of a comprehensive quality assurance and production control pro= cess and usually involves training and continuous oversight by the mos= t experienced staff. Rules for system and software development should be de= veloped. These rules should incorporate secure software development techniq= ues such as user authentication, session control, logging, and data validat= ion and sanitization. Unit, system, integration and regression testing shou= ld include testing of security requirements prior to deployment. Changes to= the system as well as its operating environments should be managed, tested= and approved. Support processes are closely related to Security Operations. As sys= tem maintenance occurs secure operational processes with regard to change c= ontrol, separation of development, test and production environments as well= as other operational controls provide many of the post implementation supp= ort processes and control.
System and acceptance testing usually requires Test data that is as close as possible to production data. Using production data fo= r test data should be avoided unless mechanisms for removing or masking&nbs= p;personally identifiable information or other sensitive information in tes= t data is developed.
Top of page
Objective: To ensure that security requirements are established as an in= tegral part of the entire lifecycle of an information system.
The acquisition of a system or application often includes a Request for = Proposals (RFP), which is a formal procurement process. During this process= , security requirements need to be identified. Indiana University includes = both a security review and a security questionnaire as part of the RFP proc= ess. Learn more about this effective practice by viewing Building Secur= ity into the RFP Process.
The University of Illinois Urbana-Champaign has developed a procurement = process for evaluating whether an electronic service is considered to be lo= w-risk, and potentially eligible for purchase using a P-Card. The criteria = are included in Pur= chasing Software and Electronic Services with a P-Card.
Many institutions are looking to the cloud for information system soluti= ons. Cl= oud Computing Security considerations are essential! Security professio= nals from EDUCAUSE member institutions published an excellent article, Cloud Services: Policy and Assessment,= in the EDUCAUSE Review. Evaluating Cloud Risk for t= he Enterprise: A Shared Assessments Guide provides information to consi= der in evaluating the risk of moving applications to the cloud. Institution= s need to perform due diligence to assess the security of cloud service pro= viders. The Cloud Security Alliance has also published several resources to= help assess security of cloud services. The Cloud Controls Matrix= may prove particularly beneficial to those who are evaluating services= prior to purchase.
George Mathew outlined security considerations for applications in the c= loud at the 2011 Security Professionals conference. His Application Security in the Cloud sessi= on was recorded. Navigating the Clouds with an Enterprise= IT Strategy, presented at the 2013 Security Professionals Conference, = offers guidance from Furman University on creating a cloud security strateg= y. The University of Pennsylvania shared experience, lessons learned, and r= ecommendations for creating a cloud policy, contracted solutions, and secur= ity assessments in Bring Your Own Clo= ud: Data Management Challenges in a Click-Through World, a presentation= at the 2013 Security Professionals Conference.
As electronic commerce and online transactions become more p= revalent, controls should be implemented to protect the information involve= d in this activity from various threats associated with this way of doing b= usiness. A review of potential information security cont= rols that can be implemented for risk reduction should be considered, such = as encryption, authorization processes, segregation of duties, network secu= rity controls, checks and balances to verify transactions, non-repudiation,= etc. Care should also be taken to verify the validity and integrity of pub= licly available information provided over the internet, and protect this in= formation from unauthorized access and compromises.
As applications are developed for mobile computing, security requirement= s need to be included from the beginning. Developing a Campu= s Mobile Strategy: Guidelines, Tools, and Best Practices is an EDUCAUSE= resource that offers an excellent strategy for mobile devices, including s= ecurity considerations.
An important aspect of overall information systems design involves the c= redentials that will be used to access the system. The InCommon Ide= ntity Assurance Profiles Bronze and Silver (IAP) document specifies req= uirements that Identity Provider Operators must meet in order to be eligibl= e to include InCommon Identity Assurance Qualifiers in Identity Assertions = that they offer to Service Providers. The IAP provides excellent security r= equirements for identity management systems. In particular, Section 4.2.3, = Credential Technology specifies requirements for issuing and securing crede= ntials. Further guidance involving credential technology can be found in NIST SP 800-63.
Top of page
Objective: To ensure that development lifecycle processes are establishe= d to maintain the security of information systems as the systems are design= ed, developed, tested, and maintained.
One of the security layers that can expose serious vulnerabilities is th= e application layer. Inventorying and securing all applications, software i= nterfaces, or integration points that "touch" sensitive data is crucial in = any organization that handles personal identity data, HIPAA, PCI, or any da= ta that can lead to identifying confidential information. Unfortunately, th= is layer is subject to extensive variations and stretches across many techn= ologies, human competencies, and organizational controls, practices, and st= andards. As such, it is difficult to secure and sustain, usually requiring = departments to re-evaluate much of their software development, acquisition,= and production control organization, staffing, and practices. Moreover, si= nce applications are enhanced to adapt to changing business needs relativel= y often, even while the technology they depend on may also be changing, a c= onsistent and "routinized" approach to maintaining their security must be a= dopted. Fortunately, there are many excellent resources to help organizatio= ns get started.
The Information Technology Infrastructure Library (ITIL) is one of the old= est and most mature frameworks for IT service management, and offers a weal= th of best practice documents.
JIRA is a project tracking tool that is very useful for bug tracking= and change management. Jira workflows can be customized and used to formal= ize testing procedures.
The need for highly skilled developers and support personnel cannot be e= mphasized enough. Security training is expensive, but can save the institut= ion both dollars and reputation in the long run. The SANS Educational I= nstitutions Program is a partnership that helps to lower the cost = of training for higher education security professionals. Relevant courses f= or software developers are listed in the SANS Secure S= oftware Development Training Curriculum. System administrators will ben= efit from the SANS System Administration Tr= aining Curriculum.
The OWASP Top Ten is a baseline for addressi= ng the most prevalent web development risks. Application developers should = be well trained in coding techniques that control these risks, and software= purchasers should require that products not be susceptible to them. At the= 2013 Security Professionals Conference, the University of Pennsylvania pre= sented a valuable methodology for securing web applications in = Proven Strategies for Web Application Security.
Top of page
Objective: To ensure the protection of data used for testing.
Data used in testing environments such as quality assurance, test and de= velopment must be protected against unauthorized access. For example, test = environments may be firewalled to restricted to campus systems. Accounts ma= y be disabled so that only a subset of accounts can be used for testing. Co= pying data between production and test environment should be approved. Wher= e possible data used for testing should not contain personally identifiable= information. Guidelines for Data De-Identification = or Anonymization should be followed to remove sensitive information or = to modify it beyond recognition when used for testing purposes. If producti= on data is used unchanged for testing, the data should be protected with th= e same level of controls used for the production system.
Top of page
EDUCAUSE Resources
Initiatives, Collaborations, & Other Resour= ces
Top of page
27002:2013 Information Security Manag=
ement |
800-53: Recommended Security=
Controls for Federal Information |
APO01.06 |
Req 2 |
PR.DS-2 |
45 CFR 164.308(a)(5) |
Top of page=
Questions or= comments? Contact us.
Except wher= e otherwise noted, this work is licensed under a Creative Commons Attributi= on-NonCommercial-ShareAlike 4.0 International License (= CC BY-NC-SA 4.0).