https://wiki.owasp.org/api.php?action=feedcontributions&feedformat=atom&user=MelDrews 2026-04-22T09:36:25Z User contributions MediaWiki 1.27.2 https://wiki.owasp.org/index.php?title=Category:Control&diff=195928 2015-06-09T01:13:55Z

<p>MelDrews: typo correction</p> <hr /> <div>This category is a parent category used to track categories of controls (or countermeasure, security mechanisms). <br /> <br /> {{Social Media Links}}<br /> <br /> ==What is a control==<br /> As an abstract category of concepts, it can be difficult to grasp where controls fit into the collection of policies, procedures, and standards that create the structures of governance, management, practices and patterns necessary to secure software and data. Where each of these conceptual business needs is addressed through documentation with differing levels of specificity, it is useful to look at where controls fit in relation to these other structures. Security controls can be categorized in several ways. One useful breakdown is the axis that includes administrative, technical and physical controls. Controls in each of these areas support the others. Another useful breakdown is along the categories of preventive, detective and corrective.<br /> <br /> ISACA defines control as the means of managing risk, including policies, procedures, guidelines, practices or organizational structures, which can be of an administrative, technical, management, or legal nature.[1]<br /> <br /> While the ISACA COBIT standard is frequently referenced with regard to information security control, the design of the standard places its guidance mostly at the level of governance with very little that will help us design or implement secure software. U.S. National Institute of Standards and Technology (NIST) Special Publication 800-53, ''Security and Privacy Controls for Federal Information Systems and Organizations'' is widely referenced for its fairly detailed catalog of security controls. It does not, however, define what a control should be.<br /> <br /> The Council on CyberSecurity Critical Security Controls list provides very little detail on specific measures we can implement in software. Among the 20 critical controls we find &quot;Application Software Security&quot; with 11 recommended implementation measures:<br /> <br /> #Patching<br /> #Implement a Web Application Firewall (WAF)<br /> #Error checking all input<br /> #Use an automated scanner to look for security weaknesses<br /> #Output sanitization of error messages<br /> #Segregation development and production environments<br /> #Secure code analysis, manual and automated<br /> #Verify vendor security processes<br /> #Database configuration hardening<br /> #Train developers on writing secure code<br /> #Remove development artifacts from production code<br /> <br /> Of these 11, it is interesting to note that two relate to infrastructure architecture, four are operational, two are part of testing processes, and only three are things that are done as part of coding.<br /> <br /> While many controls are definitely of a technical nature, it is important to distinguish the way in which controls differ from coding techniques. Many things we might think of as controls, should more properly be put into coding standards or guidelines. As an example, NIST SP800-53 suggests five controls related to session management:<br /> *Concurrent Session Control<br /> *Session Lock<br /> *Session Termination<br /> *Session Audit<br /> *Session Authenticity<br /> <br /> Note that three of these are included within the category of Access Controls. In most cases, NIST explicitly calls for the organization to define some of the elements of how these controls should be implemented.<br /> <br /> In contrast, the OWASP [[Session_Management_Cheat_Sheet]] does a very good job at illustrating session management implementation techniques and suggests some standards. These kinds of standards and guidelines spell out specific implementation of controls.<br /> <br /> While different organizations and standards will write controls at differing levels of abstraction, it is generally recognized that controls should be defined and implemented to address business needs for security. COBIT 5 makes this explicit by mapping enterprise goals to IT-related goals, process goals, management practices and activities. The management practices map to items that were described in COBIT 4 as control objectives. Each organization and process area will define their controls differently, but this alignment of controls to objectives and activities is a strong commonality between different standards. Activities are often the means by which controls are implemented. They are written out in procedures that specify the intended operation of controls. A procedure is not, in itself, a control. A given procedure may address multiple controls and a given control may require more than one procedure to fully implement.<br /> <br /> So, we've found that the concept of a security control is hard to define clearly in a way that enables practitioners to begin writing controls and putting them to use. Some definitions exist, but are open to wide interpretation and may not be adaptable to every need. At this point we can hazard some statements that may provide further clarity. Control statements should be concisely worded to specify required process outcomes. While this is very similar to a policy statement, policies are generally more oriented toward enterprise goals, whereas controls are more oriented toward process goals.<br /> <br /> A control differs from a standard in that the standard is focused on requirements for specific tools that may be used, coding structures, or techniques.<br /> <br /> [[Image:Control_support.jpg]]<br /> <br /> '''Figure 1''' - Relationship of control statements to control objectives and other documentation<br /> <br /> Necessary controls in an application should be identified using risk assessment. [[Threat modeling]] is one component of risk assessment that examines the threats, vulnerabilities and exposures of an application. Threat modeling will help to identify many of the technical controls necessary for inclusion within the application development effort. It should be combined with other risk assessment techniques that also take into account the larger organizational impacts of the application.<br /> <br /> ==Examples of controls==<br /> *[[Authentication]]<br /> *[[Authorization]]<br /> *[[Audit]]<br /> *[[Data_Security]]<br /> *[[Integrity]]<br /> <br /> ==Further References==<br /> #Glossary. ISACA. http://www.isaca.org/Pages/Glossary.aspx?tid=2011&amp;char=C As viewed on 24 May 2015.<br /> #''Cobit 5: Enabling Processes''. ISACA. (2012). http://www.isaca.org/COBIT/Pages/COBIT-5-Enabling-Processes-product-page.aspx<br /> # Joint Task Force Transformation Initiative. ''Security and Privacy Controls for Federal Information Systems and organizations''. Special Publication 800-53 revision 4. (2013) U.S. National Institute of Standards and Technology. http://dx.doi.org/10.6028/NIST.SP.800-53r4<br /> #Critical Security Controls. Center for Internet Security. Retrieved from http://www.cisecurity.org/critical-controls.cfm on 24 May 2015.<br /> <br /> {{Template:PutInCategory}}<br /> <br /> [[Category:Article Type]]<br /> [[Category:OWASP ASDR Project]]</div>

MelDrews https://wiki.owasp.org/index.php?title=Integrity&diff=195212 2015-05-24T21:33:52Z

<p>MelDrews: Initial page creation with control description</p> <hr /> <div>Data and system integrity is one of the primary goals of security, which is why we see it reflected in the common litany of C-I-A (Confidentiality, Integrity and Availability). Within the STRIDE threat modeling approach, tampering directly attacks information integrity and controls preventing spoofing and repudiation support integrity requirements.<br /> <br /> Data integrity controls guard against improper information modification or destruction, and includes ensuring information non-repudiation and authenticity.<br /> <br /> U.S. National Institute of Standards and Technology (NIST) Special Publication 800-53 includes the following controls that address integrity and may be directly reflected within software implementations:<br /> *Tamper resistance and detection (SA-18)<br /> *Transmission confidentiality and integrity (SC-8)<br /> *Protection of information at rest (SC-28)<br /> *Software, firmware and information integrity (SI-7)<br /> *Information input validation (SI-10)<br /> *Memory protection (SI-16)<br /> <br /> Accuracy of data processing and transmissions is a critical business requirement, both for decision support processes and for regulatory compliance reasons (Sarbanes-Oxley).<br /> <br /> ISO 27001:2013 includes controls related to correct processing within applications in the System acquisition, development and maintenance group.<br /> <br /> #Hernan, S., Lambert, S., Ostwald, T., and Shostack, A. ''Uncover Security Design Flaws Using the STRIDE Approach''. MSDN Magazine. Microsoft. (2006). https://msdn.microsoft.com/en-us/magazine/cc163519.aspx<br /> # Joint Task Force Transformation Initiative. ''Security and Privacy Controls for Federal Information Systems and Organizations''. Special Publication 800-53 revision 4. (2013) U.S. National Institute of Standards and Technology. http://dx.doi.org/10.6028/NIST.SP.800-53r4<br /> #ISO/IEC 27001:2013. Wikipedia. Retrieved from http://en.wikipedia.org/wiki/ISO/IEC_27001:2013 on 25 May 2015.</div>

MelDrews https://wiki.owasp.org/index.php?title=Data_Security&diff=195211 2015-05-24T20:21:52Z

<p>MelDrews: /* Further References */</p> <hr /> <div>This article addresses data security controls implemented in software features or development processes. Data Security is the name given to a group of controls within the U.S. National Institute of Standards and Technology (NIST) ''Framework for Improving Critical Infrastructure Cybersecurity'' (the Cybersecurity Framework). Subcategories within this category include:<br /> *Data at rest is protected<br /> *Data in transit is protected<br /> *Protections against data leaks are implemented<br /> <br /> Other administrative, operational and architectural controls are included as well, but the above list specifies measures that would be directly reflected in the coding of software features.<br /> <br /> NIST Special Publication 800-53 lists additional related controls within the System and Communications Protection family, which comprises 41 controls in total. Depending on the relevance in a given project, there are at least six of these that could be implemented directly as software features and map back to the Data Security category in the Cybersecurity Framework, including:<br /> *Information in shared resources<br /> *Denial of service protection<br /> *Transmission confidentiality and integrity<br /> *Cryptographic protection<br /> *Transmission of security attributes<br /> *Protection of information at rest<br /> <br /> These controls are implemented through means such as the proper use of cryptography, [[Web_Services_Architecture_and_Security|software security architecture]], [[Error_Handling,_Auditing_and_Logging#Error_Handling|error handling]], and processing labels applied to data.<br /> <br /> ISO 27001:2013 includes controls related to data security within the System acquisition, development and maintenance group.<br /> <br /> ==Further References==<br /> #''Framework for Improving Critical Infrastructure Cybersecurity''. U.S. National Institute of Standards and Technology. (2014). Retrieved from http://www.nist.gov/cyberframework/upload/cybersecurity-framework-021214-final.pdf on 24 May 2015.<br /> #Joint Task Force Transformation Initiative. ''Security and Privacy Controls for Federal Information Systems and Organizations''. Special Publication 800-53 revision 4. U.S. National Institute of Standards and Technology. (2013) http://dx.doi.org/10.6028/NIST.SP.800-53r4<br /> #ISO/IEC 27001:2013. Wikipedia. Retrieved from http://en.wikipedia.org/wiki/ISO/IEC_27001:2013 on 24 May 2015.</div>

MelDrews https://wiki.owasp.org/index.php?title=Data_Security&diff=195210 2015-05-24T20:04:31Z

<p>MelDrews: Initial page creation with control description</p> <hr /> <div>This article addresses data security controls implemented in software features or development processes. Data Security is the name given to a group of controls within the U.S. National Institute of Standards and Technology (NIST) ''Framework for Improving Critical Infrastructure Cybersecurity'' (the Cybersecurity Framework). Subcategories within this category include:<br /> *Data at rest is protected<br /> *Data in transit is protected<br /> *Protections against data leaks are implemented<br /> <br /> Other administrative, operational and architectural controls are included as well, but the above list specifies measures that would be directly reflected in the coding of software features.<br /> <br /> NIST Special Publication 800-53 lists additional related controls within the System and Communications Protection family, which comprises 41 controls in total. Depending on the relevance in a given project, there are at least six of these that could be implemented directly as software features and map back to the Data Security category in the Cybersecurity Framework, including:<br /> *Information in shared resources<br /> *Denial of service protection<br /> *Transmission confidentiality and integrity<br /> *Cryptographic protection<br /> *Transmission of security attributes<br /> *Protection of information at rest<br /> <br /> These controls are implemented through means such as the proper use of cryptography, [[Web_Services_Architecture_and_Security|software security architecture]], [[Error_Handling,_Auditing_and_Logging#Error_Handling|error handling]], and processing labels applied to data.<br /> <br /> ISO 27001:2013 includes controls related to data security within the System acquisition, development and maintenance group.<br /> <br /> ==Further References==<br /> #''Framework for Improving Critical Infrastructure Cybersecurity''. U.S. National Institute of Standards and Technology. (2014). Retrieved from http://www.nist.gov/cyberframework/upload/cybersecurity-framework-021214-final.pdf on 25 May 2015.<br /> #Joint Task Force Transformation Initiative. ''Security and Privacy Controls for Federal Information Systems and Organizations''. Special Publication 800-53 revision 4. U.S. National Institute of Standards and Technology. (2013) http://dx.doi.org/10.6028/NIST.SP.800-53r4<br /> #ISO/IEC 27001:2013. Wikipedia. Retrieved from http://en.wikipedia.org/wiki/ISO/IEC_27001:2013 on 25 May 2015.</div>

MelDrews https://wiki.owasp.org/index.php?title=Category:Control&diff=195208 2015-05-24T17:48:44Z

<p>MelDrews: Added external references</p> <hr /> <div>This category is a parent category used to track categories of controls (or countermeasure, security mechanisms). <br /> <br /> {{Social Media Links}}<br /> <br /> ==What is a control==<br /> As an abstract category of concepts, it can be difficult to grasp where controls fit into the collection of policies, procedures, and standards that create the structures of governance, management, practices and patterns necessary to secure software and data. Where each of these conceptual business needs is addressed through documentation with differing levels of specificity, it is useful to look at where controls fit in relation to these other structures. Security controls can be categorized in several ways. One useful breakdown is the axis that includes administrative, technical and physical controls. Controls in each of these areas support the others. Another useful breakdown is along the categories of preventive, detective and corrective.<br /> <br /> ISACA defines control as the means of managing risk, including policies, procedures, guidelines, practices or organizational structures, which can be of an administrative, technical, management, or legal nature.[1]<br /> <br /> While the ISACA COBIT standard is frequently referenced with regard to information security control, the design of the standard places its guidance mostly at the level of governance with very little that will help us design or implement secure software. U.S. National Institute of Standards and Technology (NIST) Special Publication 800-53, ''Security and Privacy Controls for Federal Information Systems and Organizations'' is widely referenced for its fairly detailed catalog of security controls. It does not, however, define what a control should be.<br /> <br /> The Council on CyberSecurity Critical Security Controls list provides very little detail on specific measures we can implement in software. Among the 20 critical controls we find &quot;Application Software Security&quot; with 11 recommended implementation measures:<br /> <br /> #Patching<br /> #Implement a Web Application Firewall (WAF)<br /> #Error checking all input<br /> #Use and automated scanner to look for security weaknesses<br /> #Output sanitization of error messages<br /> #Segregation development and production environments<br /> #Secure code analysis, manual and automated<br /> #Verify vendor security processes<br /> #Database configuration hardening<br /> #Train developers on writing secure code<br /> #Remove development artifacts from production code<br /> <br /> Of these 11, it is interesting to note that two relate to infrastructure architecture, four are operational, two are part of testing processes, and only three are things that are done as part of coding.<br /> <br /> While many controls are definitely of a technical nature, it is important to distinguish the way in which controls differ from coding techniques. Many things we might think of as controls, should more properly be put into coding standards or guidelines. As an example, NIST SP800-53 suggests five controls related to session management:<br /> *Concurrent Session Control<br /> *Session Lock<br /> *Session Termination<br /> *Session Audit<br /> *Session Authenticity<br /> <br /> Note that three of these are included within the category of Access Controls. In most cases, NIST explicitly calls for the organization to define some of the elements of how these controls should be implemented.<br /> <br /> In contrast, the OWASP [[Session_Management_Cheat_Sheet]] does a very good job at illustrating session management implementation techniques and suggests some standards. These kinds of standards and guidelines spell out specific implementation of controls.<br /> <br /> While different organizations and standards will write controls at differing levels of abstraction, it is generally recognized that controls should be defined and implemented to address business needs for security. COBIT 5 makes this explicit by mapping enterprise goals to IT-related goals, process goals, management practices and activities. The management practices map to items that were described in COBIT 4 as control objectives. Each organization and process area will define their controls differently, but this alignment of controls to objectives and activities is a strong commonality between different standards. Activities are often the means by which controls are implemented. They are written out in procedures that specify the intended operation of controls. A procedure is not, in itself, a control. A given procedure may address multiple controls and a given control may require more than one procedure to fully implement.<br /> <br /> So, we've found that the concept of a security control is hard to define clearly in a way that enables practitioners to begin writing controls and putting them to use. Some definitions exist, but are open to wide interpretation and may not be adaptable to every need. At this point we can hazard some statements that may provide further clarity. Control statements should be concisely worded to specify required process outcomes. While this is very similar to a policy statement, policies are generally more oriented toward enterprise goals, whereas controls are more oriented toward process goals.<br /> <br /> A control differs from a standard in that the standard is focused on requirements for specific tools that may be used, coding structures, or techniques.<br /> <br /> [[Image:Control_support.jpg]]<br /> <br /> '''Figure 1''' - Relationship of control statements to control objectives and other documentation<br /> <br /> Necessary controls in an application should be identified using risk assessment. [[Threat modeling]] is one component of risk assessment that examines the threats, vulnerabilities and exposures of an application. Threat modeling will help to identify many of the technical controls necessary for inclusion within the application development effort. It should be combined with other risk assessment techniques that also take into account the larger organizational impacts of the application.<br /> <br /> ==Examples of controls==<br /> *[[Authentication]]<br /> *[[Authorization]]<br /> *[[Audit]]<br /> *[[Data_Security]]<br /> *[[Integrity]]<br /> <br /> ==Further References==<br /> #Glossary. ISACA. http://www.isaca.org/Pages/Glossary.aspx?tid=2011&amp;char=C As viewed on 24 May 2015.<br /> #''Cobit 5: Enabling Processes''. ISACA. (2012). http://www.isaca.org/COBIT/Pages/COBIT-5-Enabling-Processes-product-page.aspx<br /> # Joint Task Force Transformation Initiative. ''Security and Privacy Controls for Federal Information Systems and organizations''. Special Publication 800-53 revision 4. (2013) U.S. National Institute of Standards and Technology. http://dx.doi.org/10.6028/NIST.SP.800-53r4<br /> #Critical Security Controls. Center for Internet Security. Retrieved from http://www.cisecurity.org/critical-controls.cfm on 24 May 2015.<br /> <br /> {{Template:PutInCategory}}<br /> <br /> [[Category:Article Type]]<br /> [[Category:OWASP ASDR Project]]</div>

MelDrews https://wiki.owasp.org/index.php?title=Category:Control&diff=195207 2015-05-24T17:38:55Z

<p>MelDrews: Removed control examples pointing to standards and techniques; added examples referenced in acknowledged standards</p> <hr /> <div>This category is a parent category used to track categories of controls (or countermeasure, security mechanisms). <br /> <br /> {{Social Media Links}}<br /> <br /> ==What is a control==<br /> As an abstract category of concepts, it can be difficult to grasp where controls fit into the collection of policies, procedures, and standards that create the structures of governance, management, practices and patterns necessary to secure software and data. Where each of these conceptual business needs is addressed through documentation with differing levels of specificity, it is useful to look at where controls fit in relation to these other structures. Security controls can be categorized in several ways. One useful breakdown is the axis that includes administrative, technical and physical controls. Controls in each of these areas support the others. Another useful breakdown is along the categories of preventive, detective and corrective.<br /> <br /> ISACA defines control as the means of managing risk, including policies, procedures, guidelines, practices or organizational structures, which can be of an administrative, technical, management, or legal nature.[1]<br /> <br /> While the ISACA COBIT standard is frequently referenced with regard to information security control, the design of the standard places its guidance mostly at the level of governance with very little that will help us design or implement secure software. U.S. National Institute of Standards and Technology (NIST) Special Publication 800-53, ''Security and Privacy Controls for Federal Information Systems and Organizations'' is widely referenced for its fairly detailed catalog of security controls. It does not, however, define what a control should be.<br /> <br /> The Council on CyberSecurity Critical Security Controls list provides very little detail on specific measures we can implement in software. Among the 20 critical controls we find &quot;Application Software Security&quot; with 11 recommended implementation measures:<br /> <br /> #Patching<br /> #Implement a Web Application Firewall (WAF)<br /> #Error checking all input<br /> #Use and automated scanner to look for security weaknesses<br /> #Output sanitization of error messages<br /> #Segregation development and production environments<br /> #Secure code analysis, manual and automated<br /> #Verify vendor security processes<br /> #Database configuration hardening<br /> #Train developers on writing secure code<br /> #Remove development artifacts from production code<br /> <br /> Of these 11, it is interesting to note that two relate to infrastructure architecture, four are operational, two are part of testing processes, and only three are things that are done as part of coding.<br /> <br /> While many controls are definitely of a technical nature, it is important to distinguish the way in which controls differ from coding techniques. Many things we might think of as controls, should more properly be put into coding standards or guidelines. As an example, NIST SP800-53 suggests five controls related to session management:<br /> *Concurrent Session Control<br /> *Session Lock<br /> *Session Termination<br /> *Session Audit<br /> *Session Authenticity<br /> <br /> Note that three of these are included within the category of Access Controls. In most cases, NIST explicitly calls for the organization to define some of the elements of how these controls should be implemented.<br /> <br /> In contrast, the OWASP [[Session_Management_Cheat_Sheet]] does a very good job at illustrating session management implementation techniques and suggests some standards. These kinds of standards and guidelines spell out specific implementation of controls.<br /> <br /> While different organizations and standards will write controls at differing levels of abstraction, it is generally recognized that controls should be defined and implemented to address business needs for security. COBIT 5 makes this explicit by mapping enterprise goals to IT-related goals, process goals, management practices and activities. The management practices map to items that were described in COBIT 4 as control objectives. Each organization and process area will define their controls differently, but this alignment of controls to objectives and activities is a strong commonality between different standards. Activities are often the means by which controls are implemented. They are written out in procedures that specify the intended operation of controls. A procedure is not, in itself, a control. A given procedure may address multiple controls and a given control may require more than one procedure to fully implement.<br /> <br /> So, we've found that the concept of a security control is hard to define clearly in a way that enables practitioners to begin writing controls and putting them to use. Some definitions exist, but are open to wide interpretation and may not be adaptable to every need. At this point we can hazard some statements that may provide further clarity. Control statements should be concisely worded to specify required process outcomes. While this is very similar to a policy statement, policies are generally more oriented toward enterprise goals, whereas controls are more oriented toward process goals.<br /> <br /> A control differs from a standard in that the standard is focused on requirements for specific tools that may be used, coding structures, or techniques.<br /> <br /> [[Image:Control_support.jpg]]<br /> <br /> '''Figure 1''' - Relationship of control statements to control objectives and other documentation<br /> <br /> Necessary controls in an application should be identified using risk assessment. [[Threat modeling]] is one component of risk assessment that examines the threats, vulnerabilities and exposures of an application. Threat modeling will help to identify many of the technical controls necessary for inclusion within the application development effort. It should be combined with other risk assessment techniques that also take into account the larger organizational impacts of the application.<br /> <br /> ==Examples of controls==<br /> *[[Authentication]]<br /> *[[Authorization]]<br /> *[[Audit]]<br /> *[[Data_Security]]<br /> *[[Integrity]]<br /> <br /> {{Template:PutInCategory}}<br /> <br /> [[Category:Article Type]]<br /> [[Category:OWASP ASDR Project]]</div>

MelDrews https://wiki.owasp.org/index.php?title=Category:Control&diff=195206 2015-05-24T17:18:41Z

<p>MelDrews: Correcting and expanding on definition of control with examples</p> <hr /> <div>This category is a parent category used to track categories of controls (or countermeasure, security mechanisms). <br /> <br /> {{Social Media Links}}<br /> <br /> ==What is a control==<br /> As an abstract category of concepts, it can be difficult to grasp where controls fit into the collection of policies, procedures, and standards that create the structures of governance, management, practices and patterns necessary to secure software and data. Where each of these conceptual business needs is addressed through documentation with differing levels of specificity, it is useful to look at where controls fit in relation to these other structures. Security controls can be categorized in several ways. One useful breakdown is the axis that includes administrative, technical and physical controls. Controls in each of these areas support the others. Another useful breakdown is along the categories of preventive, detective and corrective.<br /> <br /> ISACA defines control as the means of managing risk, including policies, procedures, guidelines, practices or organizational structures, which can be of an administrative, technical, management, or legal nature.[1]<br /> <br /> While the ISACA COBIT standard is frequently referenced with regard to information security control, the design of the standard places its guidance mostly at the level of governance with very little that will help us design or implement secure software. U.S. National Institute of Standards and Technology (NIST) Special Publication 800-53, ''Security and Privacy Controls for Federal Information Systems and Organizations'' is widely referenced for its fairly detailed catalog of security controls. It does not, however, define what a control should be.<br /> <br /> The Council on CyberSecurity Critical Security Controls list provides very little detail on specific measures we can implement in software. Among the 20 critical controls we find &quot;Application Software Security&quot; with 11 recommended implementation measures:<br /> <br /> #Patching<br /> #Implement a Web Application Firewall (WAF)<br /> #Error checking all input<br /> #Use and automated scanner to look for security weaknesses<br /> #Output sanitization of error messages<br /> #Segregation development and production environments<br /> #Secure code analysis, manual and automated<br /> #Verify vendor security processes<br /> #Database configuration hardening<br /> #Train developers on writing secure code<br /> #Remove development artifacts from production code<br /> <br /> Of these 11, it is interesting to note that two relate to infrastructure architecture, four are operational, two are part of testing processes, and only three are things that are done as part of coding.<br /> <br /> While many controls are definitely of a technical nature, it is important to distinguish the way in which controls differ from coding techniques. Many things we might think of as controls, should more properly be put into coding standards or guidelines. As an example, NIST SP800-53 suggests five controls related to session management:<br /> *Concurrent Session Control<br /> *Session Lock<br /> *Session Termination<br /> *Session Audit<br /> *Session Authenticity<br /> <br /> In most cases, NIST explicitly calls for the organization to define some of the elements of how these controls should be implemented.<br /> <br /> In contrast, the OWASP [[Session_Management_Cheat_Sheet]] does a very good job at illustrating session management implementation techniques and suggests some standards. These kinds of standards and guidelines spell out specific implementation of controls.<br /> <br /> While different organizations and standards will write controls at differing levels of abstraction, it is generally recognized that controls should be defined and implemented to address business needs for security. COBIT 5 makes this explicit by mapping enterprise goals to IT-related goals, process goals, management practices and activities. The management practices map to items that were described in COBIT 4 as control objectives. Each organization and process area will define their controls differently, but this alignment of controls to objectives and activities is a strong commonality between different standards. Activities are often the means by which controls are implemented. They are written out in procedures that specify the intended operation of controls. A procedure is not, in itself, a control. A given procedure may address multiple controls and a given control may require more than one procedure to fully implement.<br /> <br /> So, we've found that the concept of a security control is hard to define clearly in a way that enables practitioners to begin writing controls and putting them to use. Some definitions exist, but are open to wide interpretation and may not be adaptable to every need. At this point we can hazard some statements that may provide further clarity. Control statements should be concisely worded to specify required process outcomes. While this is very similar to a policy statement, policies are generally more oriented toward enterprise goals, whereas controls are more oriented toward process goals.<br /> <br /> A control differs from a standard in that the standard is focused on requirements for specific tools that may be used, coding structures, or techniques.<br /> <br /> [[Image:Control_support.jpg]]<br /> <br /> '''Figure 1''' - Relationship of control statements to control objectives and other documentation<br /> <br /> Necessary controls in an application should be identified using risk assessment. [[Threat modeling]] is one component of risk assessment that examines the threats, vulnerabilities and exposures of an application. Threat modeling will help to identify many of the technical controls necessary for inclusion within the application development effort. It should be combined with other risk assessment techniques that also take into account the larger organizational impacts of the application.<br /> <br /> ==Examples of controls==<br /> *[[Authentication]]<br /> *[[Authorization]]<br /> *[[Session Management]]<br /> *[[Input Validation]]<br /> *[[Error Handling]]<br /> *[[Logging]]<br /> *[[Cryptography]]<br /> <br /> {{Template:PutInCategory}}<br /> <br /> [[Category:Article Type]]<br /> [[Category:OWASP ASDR Project]]</div>

MelDrews https://wiki.owasp.org/index.php?title=File:Control_support.jpg&diff=195205 2015-05-24T17:08:56Z

<p>MelDrews: Relationship between controls, standards, procedures and other structures</p> <hr /> <div>Relationship between controls, standards, procedures and other structures</div>

MelDrews https://wiki.owasp.org/index.php?title=Choosing_and_Using_Security_Questions_Cheat_Sheet&diff=195190 2015-05-23T22:51:22Z

<p>MelDrews: /* Security Questions As An Additional Means Of Authenticating */ - corrected unintended implication</p> <hr /> <div> __NOTOC__<br /> &lt;div style=&quot;width:100%;height:160px;border:0,margin:0;overflow: hidden;&quot;&gt;[[File:Cheatsheets-header.jpg|link=]]&lt;/div&gt;<br /> <br /> {| style=&quot;padding: 0;margin:0;margin-top:10px;text-align:left;&quot; |-<br /> | valign=&quot;top&quot; style=&quot;border-right: 1px dotted gray;padding-right:25px;&quot; |<br /> Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}''' <br /> = Introduction =<br /> __TOC__{{TOC hidden}}<br /> <br /> This cheat sheet provides some best practice for developers to follow when choosing and using security questions to implement a &amp;quot;forgot password&amp;quot; web application feature.&lt;br&gt; <br /> <br /> = The Problem =<br /> <br /> There is no industry standard either for providing guidance to users or developers when using or implementing a Forgot Password feature. The result is that developers generally pick a set of dubious questions and implement them insecurely. They do so, not only at the risk to their users, but also--because of potential liability issues--at the risk to their organization. Ideally, passwords would be dead, or at least less important in the sense that they make up only one of several multi-factor authentication mechanisms, but the truth is that we probably are stuck with passwords just like we are stuck with Cobol. So with that in mind, what can we do to make the Forgot Password solution as palatable as possible?<br /> <br /> = Choosing Security Questions and/or Identity Data =<br /> <br /> Most of us can instantly spot a bad &amp;quot;security question&amp;quot; when we see one. You know the ones we mean. Ones like &quot;What is your favorite color?&quot; are obviously bad. But as the [http://goodsecurityquestions.com/ Good Security Questions] web site rightly points out,<br /> &amp;quot;there really are NO GOOD security questions; only fair or bad questions&amp;quot;.<br /> <br /> The reason that most organizations allow users to reset their own forgotten passwords is not because of security, but rather to reduce their own costs by reducing their volume of calls to their help desks. It's the classic convenience vs. security trade-off, and in this case, convenience (both to the organization in terms of reduced costs and to the user in terms of simpler, self-service) almost always wins out.<br /> <br /> So given that the business aspect of lower cost generally wins out, what can we do to at least raise the bar a bit?<br /> <br /> Here are some suggestions. Note that we intentionally avoid recommending specific security questions. To do so likely would be counterproductive because many developers would simply use those questions without much thinking and adversaries would immediately start harvesting that data from various social networks.<br /> <br /> == Desired Characteristics ==<br /> <br /> Any security questions or identity information presented to users to reset forgotten passwords should ideally have the following four characteristics:<br /> <br /> # '''Memorable''': If users can't remember their answers to their security questions, you have achieved nothing.<br /> # '''Consistent''': The user's answers should not change over time. For instance, asking &quot;What is the name of your significant other?&quot; may have a different answer 5 years from now.<br /> # '''Nearly universal''': The security questions should apply to a wide an audience of possible.<br /> # '''Safe''': The answers to security questions should not be something that is easily guessed, or research (e.g., something that is matter of public record).<br /> <br /> == Steps ==<br /> <br /> === Step 1) Decide on Identity Data vs Canned Questions vs. User-Created Questions ===<br /> <br /> Generally, a single HTML form should be used to collect all of the inputs to be used for later password resets. <br /> <br /> If your organization has a business relationship with users, you probably have collected some sort of additional information from your users when they registered with your web site. Such information includes, but is not limited to:<br /> <br /> * email address<br /> * last name<br /> * date of birth<br /> * account number<br /> * customer number<br /> * last 4 of social security number<br /> * zip code for address on file<br /> * street number for address on file<br /> <br /> For enhanced security, you may wish to consider asking the user for their email address first and then send an email that takes them to a private page that requests the other 2 (or more) identity factors. That way the email itself isn’t that useful because they still have to answer a bunch of ‘secret’ questions after they get to the landing page.<br /> <br /> On the other hand, if you host a web site that targets the general public, such as social networking sites, free email sites, news sites, photo sharing sites, etc., then you likely to not have this identity information and will need to use some sort of the ubiquitous &quot;security questions&quot;. However, also be sure that you collect some means to send the password reset information to some out-of-band side-channel, such as a (different) email address, an SMS texting number, etc.<br /> <br /> Believe it or not, there is a certain merit to allow your users to select from a set of several &quot;canned&quot; questions. We generally ask users to fill out the security questions as part of completing their initial user profile and often that is the very time that the user is in a hurry; they just wish to register and get about using your site. If we ask users to create their own question(s) instead, they then generally do so under some amount of duress, and thus may be more likely to come up with extremely poor questions.<br /> <br /> However, there is also some strong rationale to requiring users to create their own question(s), or at least one such question. The prevailing legal opinion seems to be if we provide some sort of reasonable guidance to users in creating their own questions and then insist on them doing so, at least some of the potential liabilities are transferred from our organizations to the users. In such cases, if user accounts get hacked because of their weak security questions (e.g., &quot;What is my favorite ice cream flavor?&quot;, etc.) then the thought is that they only have themselves to blame and thus our organizations are less likely to get sued.<br /> <br /> Since OWASP recommends in the [[Forgot Password Cheat Sheet]] that multiple security questions should be posed to the user and successfully answered before allowing a password reset, a good practice might be to require the user to select 1 or 2 questions from a set of canned questions as well as to create (a different) one of their own and then require they answer one of their selected canned questions as well as their own question.<br /> <br /> === Step 2) Review Any Canned Questions with Your Legal Department or Privacy Officer ===<br /> <br /> While most developers would generally first review any potential questions with whatever relevant business unit, it may not occur to them to review the questions with their legal department or chief privacy officer. However, this is advisable because their may be applicable laws or regulatory / compliance issues to which the questions must adhere. For example, in the telecommunications industry, the FCC's Customer Proprietary Network Information (CPNI) regulations prohibit asking customers security questions that involve &quot;personal information&quot;, so questions such as &quot;In what city were you born?&quot; are generally not allowed.<br /> <br /> === Step 3) Insist on a Minimal Length for the Answers ===<br /> <br /> Even if you pose decent security questions, because users generally dislike putting a whole lot of forethought into answering the questions, they often will just answer with something short. Answering with a short expletive is not uncommon, nor is answering with something like &quot;xxx&quot; or &quot;1234&quot;. If you tell the user that they ''should'' answer with a phrase or sentence and tell them that there is some minimal length to an acceptable answer (say 10 or 12 characters), you generally will get answers that are somewhat more resistant to guessing.<br /> <br /> === Step 4) Consider How To Securely Store the Questions and Answers ===<br /> <br /> There are two aspects to this...storing the questions and storing the answers. Obviously, the questions must be presented to the user, so the options there are store them as plaintext or as reversible ciphertext. The answers technically do not need to be ever viewed by any human so they could be stored using a secure cryptographic hash (although in principle, I am aware of some help desks that utilize the both the questions and answers for password reset and they insist on being able to ''read'' the answers rather than having to type them in; YMMV). Either way, we would always recommend at least encrypting the answers rather than storing them as plaintext. This is especially true for answers to the &quot;create your own question&quot; type as users will sometimes pose a question that potentially has a sensitive answer (e.g., &quot;What is my bank account # that I share with my wife?&quot;).<br /> <br /> So the main question is whether or not you should store the questions as plaintext or reversible ciphertext. Admittedly, we are a bit biased, but for the &quot;create your own question&quot; types at least, we recommend that such questions be encrypted. This is because if they are encrypted, it makes it much less likely that your company will be sued if you have some bored, rogue DBAs pursuing the DB where the security questions and answers are stored in an attempt to amuse themselves and stumble upon something sensitive or perhaps embarrassing.<br /> <br /> In addition, if you explain to your customers that you are encrypting their questions and hashing their answers, they might feel safer about asking some questions that while potentially embarrassing, might be a bit more secure. (Use your imagination. Do we need to spell it out for you? Really???)<br /> <br /> === Step 5) Periodically Have Your Users Review their Questions ===<br /> <br /> Many companies often ask their users to update their user profiles to make sure contact information such as email addresses, street address, etc. is still up-to-date. Use that opportunity to have your users review their security questions. (Hopefully, at that time, they will be in a bit less of a rush, and may use the opportunity to select better questions.) If you had chosen to encrypt rather than hash their answers, you can also display their corresponding security answers at that time.<br /> <br /> If you keep statistics on how many times the respective questions has been posed to someone as part of a Forgot Password flow (recommended), it would be advisable to also display that information. (For instance, if against your advice, they created a question such as &quot;What is my favorite hobby?&quot; and see that it had been presented 113 times and they think they might have only reset their password 5 times, it would probably be advisable to change that security question and probably their password as well.)<br /> <br /> === Step 6) Authenticate Requests to Change Questions ===<br /> <br /> Many web sites properly authenticate change password requests simply by requesting the current password along with the desired new password. If the user cannot provide the correct current password, the request to change the password is ignored. The same authentication control should be in place when changing security questions. The user should be required to provide the correct password along with their new security questions &amp; answers. If the user cannot provide the correct password, then the request to change the security questions should be ignored. This control prevents both Cross-Site Request Forgery attacks, as well as changes made by attackers who have taken control over a users workstation or authenticated application session.<br /> <br /> = Using Security Questions =<br /> <br /> Requiring users to answer security questions is most frequently done under two quite different scenarios:<br /> * As a means for users to reset forgotten passwords. (See [[Forgot Password Cheat Sheet]].)<br /> * As an additional means of corroborating evidence used for authentication.<br /> <br /> If at anytime you intend for your users to answer security questions for both of these scenarios, it is ''strongly'' recommended that you use two different sets of questions / answers.<br /> <br /> It should noted that using a security question / answer in addition to using passwords does '''''not''''' give you multi-factor authentication because both of these fall under the category of &quot;what you know&quot;. Hence they are two of the ''same'' factor, which is not multi-factor. Furthermore, it should be noted that while passwords are a very weak form of authentication, answering security questions are generally is a much weaker form. This is because when we have users create passwords, we generally test the candidate password against some password complexity rules (e.g., minimal length &amp;gt; 10 characters; must have at least one alphabetic, one numeric, and one special character; etc.); we usually do no such thing for security answers (except for perhaps some minimal length requirement). Thus good passwords generally will have much more entropy than answers to security questions, often by several orders of magnitude.<br /> <br /> === Security Questions Used To Reset Forgotten Passwords ===<br /> <br /> The [[Forgot Password Cheat Sheet]] already details pretty much everything that you need to know as a developer when ''collecting'' answers to security questions. However, it provides no guidance about how to assist the user in selecting security questions (if chosen from a list of candidate questions) or writing their own security questions / answers. Indeed, the [[Forgot Password Cheat Sheet]] makes the assumption that one can actually use additional ''identity'' data as the security questions / answers. However, often this is not the case as the user has never (or won't) volunteer it or is it prohibited for compliance reasons with certain regulations (e.g., as in the case of telecommunications companies and [[http://en.wikipedia.org/wiki/Customer_proprietary_network_information CPNI]] data).<br /> <br /> Therefore, at least some development teams will be faced with collecting more generic security questions and answers from their users. If you must do this as a developer, it is good practice to:<br /> * briefly describe the importance of selecting a good security question / answer.<br /> * provide some guidance, along with some examples, of what constitutes bad vs. fair security questions.<br /> <br /> You may wish to refer your users to the [[http://goodsecurityquestions.com/ Good Security Questions]] web site for the latter.<br /> <br /> Furthermore, since adversaries will try the &quot;forgot password&quot; reset flow to reset a user's password (especially if they have compromised the side-channel, such as user's email account or their mobile device where they receive SMS text messages), is a good practice to minimize unintended and unauthorized information disclosure of the security questions. This may mean that you require the user to answer one security question before displaying any subsequent questions to be answered. In this manner, it does not allow an adversary an opportunity to research all the questions at once. Note however that this is contrary to the advice given on the [[Forgot Password Cheat Sheet]] and it may also be perceived as not being user-friendly by your sponsoring business unit, so again YMMV.<br /> <br /> Lastly, you should consider whether or not you should treat the security questions that a user will type in as a &quot;password&quot; type or simply as regular &quot;text&quot; input. The former can prevent shoulder-surfing attacks, but also cause more typos, so there is a trade-off. Perhaps the best advice is to give the user a choice; hide the text by treating it as &quot;password&quot; input type by default, but all the user to check a box that would display their security answers as clear text when checked.<br /> <br /> === Security Questions As An Additional Means Of Authenticating ===<br /> <br /> First, it bears repeating again...if passwords are considered weak authentication, than using security questions are even less robust. Furthermore, they are no substitute for true multi-factor authentication, or stronger forms of authentication such as authentication using one-time passwords or involving side-channel communications. In a word, very little is gained by using security questions in this context. But, if you must...keep these things in mind:<br /> <br /> * Display the security question(s) on a separate page only ''after'' your users have successfully authenticated with their usernames / passwords (rather than only after they have entered their username). In this manner, you at least do not allow an adversary to view and research the security questions unless they also know the user's current password.<br /> * If you also use security questions to reset a user's password, then you should use a ''different'' set of security questions for an additional means of authenticating.<br /> * Security questions used for actual authentication purposes should regularly expire much like passwords. Periodically make the user choose new security questions and answers.<br /> * If you use answers to security questions as a ''subsequent'' authentication mechanism (say to enter a more sensitive area of your web site), make sure that you keep the session idle time out very low...say less than 5 minutes or so, or that you also require the user to first re-authenticate with their password and then immediately after answer the security question(s).<br /> <br /> = Related Articles =<br /> [[Forgot Password Cheat Sheet]]&lt;br/&gt;<br /> [http://goodsecurityquestions.com/ Good Security Questions web site]<br /> <br /> = Authors and Primary Editors =<br /> <br /> Kevin Wall - kevin.w.wall[at]gmail com<br /> | valign=&quot;top&quot; style=&quot;padding-left:25px;width:300px;border-right: 1px dotted gray;padding-right:25px;&quot; |<br /> <br /> == Other Cheatsheets ==<br /> <br /> {{Cheatsheet_Navigation_Body}}<br /> <br /> |}<br /> <br /> [[Category:Cheatsheets]]</div>

MelDrews https://wiki.owasp.org/index.php?title=Authorization&diff=195184 2015-05-23T19:28:07Z

<p>MelDrews: Added control &quot;Account management&quot;</p> <hr /> <div>== Introduction: ==<br /> This article focuses on the authorization aspects of access controls as they are reflected in software designs, implementations and the management of software development lifecycles. Some sources include both authentication and authorization as aspects of access control. These are closely related but separate concepts and are managed through different processes. The granting of authorization is an administrative control. The enforcement of authorization through software mechanisms is referred to as access control.<br /> <br /> <br /> ISO 27000:2014 defines access control as meaning to ensure that access to assets is authorized and restricted based on business and security requirements.<br /> <br /> <br /> The definitions of access control provided in U.S. National Institute of Standards and Technology (NIST) Special Publication 800-53 (SP800-53) are context specific and not given a general definition. We do find, however, that the Access Control family of controls focuses on both authentication and authorization.<br /> <br /> <br /> The Information Security Forum Standard of Good Practice (2014) includes Access Control and User Authorization as separate controls within the Access Management control group. Authorization privileges are discussed there in Access Control (CF6.1.6), among others.<br /> <br /> <br /> All of these standards are frequently referenced sources of good guidance on access controls.<br /> <br /> == Definitions: ==<br /> Based on the guidance of such standards and common usage in the field, the following definitions are proposed:<br /> <br /> <br /> Authorization controls govern decisions and processes of determining, documenting and managing the subjects (users, devices or processes) that should be granted access and the objects to which they should be granted access; essentially, what is allowed.<br /> <br /> <br /> Access controls govern the methods and conditions of enforcement by which subjects (users, devices or processes) are allowed to or restricted from connecting with, viewing, consuming, entering into or making use of identified information resources (objects). <br /> <br /> == Some Generic Types of Access Controls: ==<br /> When thinking of access control, you might first think of the ability to login to a system or access files or a database. Access can be controlled, however, at various levels and with respect to a wide range of subjects and objects. Some examples include:<br /> <br /> * Network access - the ability to connect to a system or service;<br /> * At the host - access to operating system functionality;<br /> * Physical access - at locations housing information assets or physical access to the assets themselves;<br /> * Restricted functions - operations evaluated as having an elevated risk, such as financial transactions, changes to system configuration, or security administration.<br /> <br /> Resource access may refer not only to files and database functionality, but to:<br /> <br /> * applications or APIs;<br /> * specific application screens or functions;<br /> * specific data fields;<br /> * memory;<br /> * private or protected variables;<br /> * storage media;<br /> * transmission media;<br /> * In short, any object used in processing, storage or transmission of information.<br /> <br /> == Access Control Models: ==<br /> '''Discretionary access controls''' are based on the identity and need-to-know of subjects and/or the groups to which they belong. They are discretionary in the sense that a subject with certain access permissions is capable of passing on that access, directly or indirectly, to other subjects.<br /> <br /> <br /> '''Mandatory access controls''' are based on the sensitivity of the information contained in the objects / resources and a formal authorization. They are mandatory in the sense that they restrain subjects from setting security attributes on an object and from passing on their access.<br /> <br /> <br /> '''Role-based access controls (RBAC)''' are based on the roles played by users and groups in organizational functions. Roles, alternatively referred to as security groups, include collections of subjects that all share common needs for access. Authorization for access is then provided to the role or group and inherited by members.<br /> <br /> <br /> '''Attribute-based access control (ABAC)''' is a newer paradigm based on properties of an information exchange that may include identified attributes of the requesting entity, the resource requested, or the context of the exchange or the requested action. Some examples of contextual attributes are things such as:<br /> <br /> * time of day;<br /> * location;<br /> * currently evaluated threat level;<br /> * required hygiene measures implemented on the respective hosts.<br /> <br /> In general, in ABAC, a rules engine evaluates the identified attributes to issue an authorization decision.<br /> <br /> == Examples of Access Controls in Software: ==<br /> * Account management;<br /> * Mapping of user rights to business and process requirements;<br /> * Mechanisms that enforce policies over information flow;<br /> * Limits on the number of concurrent sessions;<br /> * Session lock after a period of inactivity;<br /> * Session termination after a period of inactivity, total time of use or time of day;<br /> * Limitations on the number of records returned from a query (data mining);<br /> * Features enforcing policies over segregation of duties;<br /> * Segregation and management of privileged user accounts;<br /> * Implementation of the principle of least privilege for granting access;<br /> * Requiring VPN (virtual private network) for access;<br /> * Dynamic reconfiguration of user interfaces based on authorization;<br /> * Restriction of access after a certain time of day.<br /> <br /> == Related resources: ==<br /> # Joint Task Force Transformation Initiative. ''Security and Privacy Controls for Federal Information Systems and Organizations''. Special Publication 800-53 revision 4. (2013) U.S. National Institute of Standards and Technology. http://dx.doi.org/10.6028/NIST.SP.800-53r4<br /> # Joint Technical Committee 1, ''Information Technology'', Subcommittee 27, ''IT Security Techniques''. ''Information Technology - Security Techniques - Information Security Management Systems - Overview and Vocabulary''. ISO/IEC. (2014). http://standards.iso.org/ittf/PubliclyAvailableStandards/c063411_ISO_IEC_27000_2014.zip<br /> # ''The Standard of Good Practice for Information Security''. Information Security Forum. (2014). https://www.securityforum.org/shop/p-71-173<br /> # DSS05 within ''Cobit 5: Enabling Processes''. ISACA. (2012). http://www.isaca.org/COBIT/Pages/COBIT-5-Enabling-Processes-product-page.aspx<br /> # OWASP [[Access Control Cheat Sheet]]<br /> # OWASP [[Guide to Authorization]]<br /> <br /> [[Category:Control]]<br /> <br /> [[Category:Countermeasure]]<br /> <br /> [[Category:Access_Control]]</div>

MelDrews https://wiki.owasp.org/index.php?title=Authorization&diff=195183 2015-05-23T17:59:30Z

<p>MelDrews: Remove extraneous spacing</p> <hr /> <div>== Introduction: ==<br /> This article focuses on the authorization aspects of access controls as they are reflected in software designs, implementations and the management of software development lifecycles. Some sources include both authentication and authorization as aspects of access control. These are closely related but separate concepts and are managed through different processes. The granting of authorization is an administrative control. The enforcement of authorization through software mechanisms is referred to as access control.<br /> <br /> <br /> ISO 27000:2014 defines access control as meaning to ensure that access to assets is authorized and restricted based on business and security requirements.<br /> <br /> <br /> The definitions of access control provided in U.S. National Institute of Standards and Technology (NIST) Special Publication 800-53 (SP800-53) are context specific and not given a general definition. We do find, however, that the Access Control family of controls focuses on both authentication and authorization.<br /> <br /> <br /> The Information Security Forum Standard of Good Practice (2014) includes Access Control and User Authorization as separate controls within the Access Management control group. Authorization privileges are discussed there in Access Control (CF6.1.6), among others.<br /> <br /> <br /> All of these standards are frequently referenced sources of good guidance on access controls.<br /> <br /> == Definitions: ==<br /> Based on the guidance of such standards and common usage in the field, the following definitions are proposed:<br /> <br /> <br /> Authorization controls govern decisions and processes of determining, documenting and managing the subjects (users, devices or processes) that should be granted access and the objects to which they should be granted access; essentially, what is allowed.<br /> <br /> <br /> Access controls govern the methods and conditions of enforcement by which subjects (users, devices or processes) are allowed to or restricted from connecting with, viewing, consuming, entering into or making use of identified information resources (objects). <br /> <br /> == Some Generic Types of Access Controls: ==<br /> When thinking of access control, you might first think of the ability to login to a system or access files or a database. Access can be controlled, however, at various levels and with respect to a wide range of subjects and objects. Some examples include:<br /> <br /> * Network access - the ability to connect to a system or service;<br /> * At the host - access to operating system functionality;<br /> * Physical access - at locations housing information assets or physical access to the assets themselves;<br /> * Restricted functions - operations evaluated as having an elevated risk, such as financial transactions, changes to system configuration, or security administration.<br /> <br /> Resource access may refer not only to files and database functionality, but to:<br /> <br /> * applications or APIs;<br /> * specific application screens or functions;<br /> * specific data fields;<br /> * memory;<br /> * private or protected variables;<br /> * storage media;<br /> * transmission media;<br /> * In short, any object used in processing, storage or transmission of information.<br /> <br /> == Access Control Models: ==<br /> '''Discretionary access controls''' are based on the identity and need-to-know of subjects and/or the groups to which they belong. They are discretionary in the sense that a subject with certain access permissions is capable of passing on that access, directly or indirectly, to other subjects.<br /> <br /> <br /> '''Mandatory access controls''' are based on the sensitivity of the information contained in the objects / resources and a formal authorization. They are mandatory in the sense that they restrain subjects from setting security attributes on an object and from passing on their access.<br /> <br /> <br /> '''Role-based access controls (RBAC)''' are based on the roles played by users and groups in organizational functions. Roles, alternatively referred to as security groups, include collections of subjects that all share common needs for access. Authorization for access is then provided to the role or group and inherited by members.<br /> <br /> <br /> '''Attribute-based access control (ABAC)''' is a newer paradigm based on properties of an information exchange that may include identified attributes of the requesting entity, the resource requested, or the context of the exchange or the requested action. Some examples of contextual attributes are things such as:<br /> <br /> * time of day;<br /> * location;<br /> * currently evaluated threat level;<br /> * required hygiene measures implemented on the respective hosts.<br /> <br /> In general, in ABAC, a rules engine evaluates the identified attributes to issue an authorization decision.<br /> <br /> == Examples of Access Controls in Software: ==<br /> * Mapping of user rights to business and process requirements;<br /> * Mechanisms that enforce policies over information flow;<br /> * Limits on the number of concurrent sessions;<br /> * Session lock after a period of inactivity;<br /> * Session termination after a period of inactivity, total time of use or time of day;<br /> * Limitations on the number of records returned from a query (data mining);<br /> * Features enforcing policies over segregation of duties;<br /> * Segregation and management of privileged user accounts;<br /> * Implementation of the principle of least privilege for granting access;<br /> * Requiring VPN (virtual private network) for access;<br /> * Dynamic reconfiguration of user interfaces based on authorization;<br /> * Restriction of access after a certain time of day.<br /> <br /> == Related resources: ==<br /> # Joint Task Force Transformation Initiative. ''Security and Privacy Controls for Federal Information Systems and Organizations''. Special Publication 800-53 revision 4. (2013) U.S. National Institute of Standards and Technology. http://dx.doi.org/10.6028/NIST.SP.800-53r4<br /> # Joint Technical Committee 1, ''Information Technology'', Subcommittee 27, ''IT Security Techniques''. ''Information Technology - Security Techniques - Information Security Management Systems - Overview and Vocabulary''. ISO/IEC. (2014). http://standards.iso.org/ittf/PubliclyAvailableStandards/c063411_ISO_IEC_27000_2014.zip<br /> # ''The Standard of Good Practice for Information Security''. Information Security Forum. (2014). https://www.securityforum.org/shop/p-71-173<br /> # DSS05 within ''Cobit 5: Enabling Processes''. ISACA. (2012). http://www.isaca.org/COBIT/Pages/COBIT-5-Enabling-Processes-product-page.aspx<br /> # OWASP [[Access Control Cheat Sheet]]<br /> # OWASP [[Guide to Authorization]]<br /> <br /> [[Category:Control]]<br /> <br /> [[Category:Countermeasure]]<br /> <br /> [[Category:Access_Control]]</div>

MelDrews https://wiki.owasp.org/index.php?title=Authorization&diff=195182 2015-05-23T17:58:11Z

<p>MelDrews: Added clarification of connection between authorization and access control</p> <hr /> <div>== Introduction: ==<br /> This article focuses on the authorization aspects of access controls as they are reflected in software designs, implementations and the management of software development lifecycles. Some sources include both authentication and authorization as aspects of access control. These are closely related but separate concepts and are managed through different processes. The granting of authorization is an administrative control. The enforcement of authorization through software mechanisms is referred to as access control.<br /> <br /> <br /> ISO 27000:2014 defines access control as meaning to ensure that access to assets is authorized and restricted based on business and security requirements.<br /> <br /> <br /> The definitions of access control provided in U.S. National Institute of Standards and Technology (NIST) Special Publication 800-53 (SP800-53) are context specific and not given a general definition. We do find, however, that the Access Control family of controls focuses on both authentication and authorization.<br /> <br /> <br /> The Information Security Forum Standard of Good Practice (2014) includes Access Control and User Authorization as separate controls within the Access Management control group. Authorization privileges are discussed there in Access Control (CF6.1.6), among others.<br /> <br /> <br /> All of these standards are frequently referenced sources of good guidance on access controls.<br /> <br /> == Definitions: ==<br /> Based on the guidance of such standards and common usage in the field, the following definitions are proposed:<br /> <br /> <br /> Authorization controls govern decisions and processes of determining, documenting and managing the subjects (users, devices or processes) that should be granted access and the objects to which they should be granted access; essentially, what is allowed.<br /> <br /> <br /> Access controls govern the methods and conditions of enforcement by which subjects (users, devices or processes) are allowed to or restricted from connecting with, viewing, consuming, entering into or making use of identified information resources (objects). <br /> <br /> == Some Generic Types of Access Controls: ==<br /> When thinking of access control, you might first think of the ability to login to a system or access files or a database. Access can be controlled, however, at various levels and with respect to a wide range of subjects and objects. Some examples include:<br /> <br /> <br /> * Network access - the ability to connect to a system or service;<br /> * At the host - access to operating system functionality;<br /> * Physical access - at locations housing information assets or physical access to the assets themselves;<br /> * Restricted functions - operations evaluated as having an elevated risk, such as financial transactions, changes to system configuration, or security administration.<br /> <br /> Resource access may refer not only to files and database functionality, but to:<br /> <br /> * applications or APIs;<br /> * specific application screens or functions;<br /> * specific data fields;<br /> * memory;<br /> * private or protected variables;<br /> * storage media;<br /> * transmission media;<br /> * In short, any object used in processing, storage or transmission of information.<br /> <br /> == Access Control Models: ==<br /> '''Discretionary access controls''' are based on the identity and need-to-know of subjects and/or the groups to which they belong. They are discretionary in the sense that a subject with certain access permissions is capable of passing on that access, directly or indirectly, to other subjects.<br /> <br /> <br /> '''Mandatory access controls''' are based on the sensitivity of the information contained in the objects / resources and a formal authorization. They are mandatory in the sense that they restrain subjects from setting security attributes on an object and from passing on their access.<br /> <br /> <br /> '''Role-based access controls (RBAC)''' are based on the roles played by users and groups in organizational functions. Roles, alternatively referred to as security groups, include collections of subjects that all share common needs for access. Authorization for access is then provided to the role or group and inherited by members.<br /> <br /> <br /> '''Attribute-based access control (ABAC)''' is a newer paradigm based on properties of an information exchange that may include identified attributes of the requesting entity, the resource requested, or the context of the exchange or the requested action. Some examples of contextual attributes are things such as:<br /> <br /> * time of day;<br /> * location;<br /> * currently evaluated threat level;<br /> * required hygiene measures implemented on the respective hosts.<br /> <br /> In general, in ABAC, a rules engine evaluates the identified attributes to issue an authorization decision.<br /> <br /> == Examples of Access Controls in Software: ==<br /> * Mapping of user rights to business and process requirements;<br /> * Mechanisms that enforce policies over information flow;<br /> * Limits on the number of concurrent sessions;<br /> * Session lock after a period of inactivity;<br /> * Session termination after a period of inactivity, total time of use or time of day;<br /> * Limitations on the number of records returned from a query (data mining);<br /> * Features enforcing policies over segregation of duties;<br /> * Segregation and management of privileged user accounts;<br /> * Implementation of the principle of least privilege for granting access;<br /> * Requiring VPN (virtual private network) for access;<br /> * Dynamic reconfiguration of user interfaces based on authorization;<br /> * Restriction of access after a certain time of day.<br /> <br /> == Related resources: ==<br /> # Joint Task Force Transformation Initiative. ''Security and Privacy Controls for Federal Information Systems and Organizations''. Special Publication 800-53 revision 4. (2013) U.S. National Institute of Standards and Technology. http://dx.doi.org/10.6028/NIST.SP.800-53r4<br /> # Joint Technical Committee 1, ''Information Technology'', Subcommittee 27, ''IT Security Techniques''. ''Information Technology - Security Techniques - Information Security Management Systems - Overview and Vocabulary''. ISO/IEC. (2014). http://standards.iso.org/ittf/PubliclyAvailableStandards/c063411_ISO_IEC_27000_2014.zip<br /> # ''The Standard of Good Practice for Information Security''. Information Security Forum. (2014). https://www.securityforum.org/shop/p-71-173<br /> # DSS05 within ''Cobit 5: Enabling Processes''. ISACA. (2012). http://www.isaca.org/COBIT/Pages/COBIT-5-Enabling-Processes-product-page.aspx<br /> # OWASP [[Access Control Cheat Sheet]]<br /> # OWASP [[Guide to Authorization]]<br /> <br /> [[Category:Control]]<br /> <br /> [[Category:Countermeasure]]<br /> <br /> [[Category:Access_Control]]</div>

MelDrews https://wiki.owasp.org/index.php?title=Authorization&diff=195181 2015-05-23T17:35:43Z

<p>MelDrews: Changed heading</p> <hr /> <div>== Introduction: ==<br /> This article focuses on the authorization aspects of access controls as they are reflected in software designs, implementations and the management of software development lifecycles. Some sources include both authentication and authorization as aspects of access control. These are closely related but separate concepts and are managed through different processes.<br /> <br /> <br /> ISO 27000:2014 defines access control as meaning to ensure that access to assets is authorized and restricted based on business and security requirements.<br /> <br /> <br /> The definitions of access control provided in U.S. National Institute of Standards and Technology (NIST) Special Publication 800-53 (SP800-53) are context specific and not given a general definition. We do find, however, that the Access Control family of controls focuses on both authentication and authorization.<br /> <br /> <br /> The Information Security Forum Standard of Good Practice (2014) includes Access Control and User Authorization as separate controls within the Access Management control group. Authorization privileges are discussed there in Access Control (CF6.1.6), among others.<br /> <br /> <br /> All of these standards are frequently referenced sources of good guidance on access controls.<br /> <br /> == Definitions: ==<br /> Based on the guidance of such standards and common usage in the field, the following definitions are proposed:<br /> <br /> <br /> Authorization controls govern decisions and processes of determining, documenting and managing the subjects (users, devices or processes) that should be granted access and the objects to which they should be granted access; essentially, what is allowed.<br /> <br /> <br /> Access controls govern the methods and conditions of enforcement by which subjects (users, devices or processes) are allowed to or restricted from connecting with, viewing, consuming, entering into or making use of identified information resources (objects). <br /> <br /> == Some Generic Types of Access Controls: ==<br /> When thinking of access control, you might first think of the ability to login to a system or access files or a database. Access can be controlled, however, at various levels and with respect to a wide range of subjects and objects. Some examples include:<br /> <br /> <br /> * Network access - the ability to connect to a system or service;<br /> * At the host - access to operating system functionality;<br /> * Physical access - at locations housing information assets or physical access to the assets themselves;<br /> * Restricted functions - operations evaluated as having an elevated risk, such as financial transactions, changes to system configuration, or security administration.<br /> <br /> Resource access may refer not only to files and database functionality, but to:<br /> <br /> * applications or APIs;<br /> * specific application screens or functions;<br /> * specific data fields;<br /> * memory;<br /> * private or protected variables;<br /> * storage media;<br /> * transmission media;<br /> * In short, any object used in processing, storage or transmission of information.<br /> <br /> == Access Control Models: ==<br /> '''Discretionary access controls''' are based on the identity and need-to-know of subjects and/or the groups to which they belong. They are discretionary in the sense that a subject with certain access permissions is capable of passing on that access, directly or indirectly, to other subjects.<br /> <br /> <br /> '''Mandatory access controls''' are based on the sensitivity of the information contained in the objects / resources and a formal authorization. They are mandatory in the sense that they restrain subjects from setting security attributes on an object and from passing on their access.<br /> <br /> <br /> '''Role-based access controls (RBAC)''' are based on the roles played by users and groups in organizational functions. Roles, alternatively referred to as security groups, include collections of subjects that all share common needs for access. Authorization for access is then provided to the role or group and inherited by members.<br /> <br /> <br /> '''Attribute-based access control (ABAC)''' is a newer paradigm based on properties of an information exchange that may include identified attributes of the requesting entity, the resource requested, or the context of the exchange or the requested action. Some examples of contextual attributes are things such as:<br /> <br /> * time of day;<br /> * location;<br /> * currently evaluated threat level;<br /> * required hygiene measures implemented on the respective hosts.<br /> <br /> In general, in ABAC, a rules engine evaluates the identified attributes to issue an authorization decision.<br /> <br /> == Examples of Access Controls in Software: ==<br /> * Mapping of user rights to business and process requirements;<br /> * Mechanisms that enforce policies over information flow;<br /> * Limits on the number of concurrent sessions;<br /> * Session lock after a period of inactivity;<br /> * Session termination after a period of inactivity, total time of use or time of day;<br /> * Limitations on the number of records returned from a query (data mining);<br /> * Features enforcing policies over segregation of duties;<br /> * Segregation and management of privileged user accounts;<br /> * Implementation of the principle of least privilege for granting access;<br /> * Requiring VPN (virtual private network) for access;<br /> * Dynamic reconfiguration of user interfaces based on authorization;<br /> * Restriction of access after a certain time of day.<br /> <br /> == Related resources: ==<br /> # Joint Task Force Transformation Initiative. ''Security and Privacy Controls for Federal Information Systems and Organizations''. Special Publication 800-53 revision 4. (2013) U.S. National Institute of Standards and Technology. http://dx.doi.org/10.6028/NIST.SP.800-53r4<br /> # Joint Technical Committee 1, ''Information Technology'', Subcommittee 27, ''IT Security Techniques''. ''Information Technology - Security Techniques - Information Security Management Systems - Overview and Vocabulary''. ISO/IEC. (2014). http://standards.iso.org/ittf/PubliclyAvailableStandards/c063411_ISO_IEC_27000_2014.zip<br /> # ''The Standard of Good Practice for Information Security''. Information Security Forum. (2014). https://www.securityforum.org/shop/p-71-173<br /> # DSS05 within ''Cobit 5: Enabling Processes''. ISACA. (2012). http://www.isaca.org/COBIT/Pages/COBIT-5-Enabling-Processes-product-page.aspx<br /> # OWASP [[Access Control Cheat Sheet]]<br /> # OWASP [[Guide to Authorization]]<br /> <br /> [[Category:Control]]<br /> <br /> [[Category:Countermeasure]]<br /> <br /> [[Category:Access_Control]]</div>

MelDrews https://wiki.owasp.org/index.php?title=Authorization&diff=195180 2015-05-23T17:34:32Z

<p>MelDrews: grammar correction</p> <hr /> <div>= Authorization / Access Control: =<br /> This article focuses on the authorization aspects of access controls as they are reflected in software designs, implementations and the management of software development lifecycles. Some sources include both authentication and authorization as aspects of access control. These are closely related but separate concepts and are managed through different processes.<br /> <br /> <br /> ISO 27000:2014 defines access control as meaning to ensure that access to assets is authorized and restricted based on business and security requirements.<br /> <br /> <br /> The definitions of access control provided in U.S. National Institute of Standards and Technology (NIST) Special Publication 800-53 (SP800-53) are context specific and not given a general definition. We do find, however, that the Access Control family of controls focuses on both authentication and authorization.<br /> <br /> <br /> The Information Security Forum Standard of Good Practice (2014) includes Access Control and User Authorization as separate controls within the Access Management control group. Authorization privileges are discussed there in Access Control (CF6.1.6), among others.<br /> <br /> <br /> All of these standards are frequently referenced sources of good guidance on access controls.<br /> <br /> == Definitions: ==<br /> Based on the guidance of such standards and common usage in the field, the following definitions are proposed:<br /> <br /> <br /> Authorization controls govern decisions and processes of determining, documenting and managing the subjects (users, devices or processes) that should be granted access and the objects to which they should be granted access; essentially, what is allowed.<br /> <br /> <br /> Access controls govern the methods and conditions of enforcement by which subjects (users, devices or processes) are allowed to or restricted from connecting with, viewing, consuming, entering into or making use of identified information resources (objects). <br /> <br /> == Some Generic Types of Access Controls: ==<br /> When thinking of access control, you might first think of the ability to login to a system or access files or a database. Access can be controlled, however, at various levels and with respect to a wide range of subjects and objects. Some examples include:<br /> <br /> <br /> * Network access - the ability to connect to a system or service;<br /> * At the host - access to operating system functionality;<br /> * Physical access - at locations housing information assets or physical access to the assets themselves;<br /> * Restricted functions - operations evaluated as having an elevated risk, such as financial transactions, changes to system configuration, or security administration.<br /> <br /> Resource access may refer not only to files and database functionality, but to:<br /> <br /> * applications or APIs;<br /> * specific application screens or functions;<br /> * specific data fields;<br /> * memory;<br /> * private or protected variables;<br /> * storage media;<br /> * transmission media;<br /> * In short, any object used in processing, storage or transmission of information.<br /> <br /> == Access Control Models: ==<br /> '''Discretionary access controls''' are based on the identity and need-to-know of subjects and/or the groups to which they belong. They are discretionary in the sense that a subject with certain access permissions is capable of passing on that access, directly or indirectly, to other subjects.<br /> <br /> <br /> '''Mandatory access controls''' are based on the sensitivity of the information contained in the objects / resources and a formal authorization. They are mandatory in the sense that they restrain subjects from setting security attributes on an object and from passing on their access.<br /> <br /> <br /> '''Role-based access controls (RBAC)''' are based on the roles played by users and groups in organizational functions. Roles, alternatively referred to as security groups, include collections of subjects that all share common needs for access. Authorization for access is then provided to the role or group and inherited by members.<br /> <br /> <br /> '''Attribute-based access control (ABAC)''' is a newer paradigm based on properties of an information exchange that may include identified attributes of the requesting entity, the resource requested, or the context of the exchange or the requested action. Some examples of contextual attributes are things such as:<br /> <br /> * time of day;<br /> * location;<br /> * currently evaluated threat level;<br /> * required hygiene measures implemented on the respective hosts.<br /> <br /> In general, in ABAC, a rules engine evaluates the identified attributes to issue an authorization decision.<br /> <br /> == Examples of Access Controls in Software: ==<br /> * Mapping of user rights to business and process requirements;<br /> * Mechanisms that enforce policies over information flow;<br /> * Limits on the number of concurrent sessions;<br /> * Session lock after a period of inactivity;<br /> * Session termination after a period of inactivity, total time of use or time of day;<br /> * Limitations on the number of records returned from a query (data mining);<br /> * Features enforcing policies over segregation of duties;<br /> * Segregation and management of privileged user accounts;<br /> * Implementation of the principle of least privilege for granting access;<br /> * Requiring VPN (virtual private network) for access;<br /> * Dynamic reconfiguration of user interfaces based on authorization;<br /> * Restriction of access after a certain time of day.<br /> <br /> == Related resources: ==<br /> # Joint Task Force Transformation Initiative. ''Security and Privacy Controls for Federal Information Systems and Organizations''. Special Publication 800-53 revision 4. (2013) U.S. National Institute of Standards and Technology. http://dx.doi.org/10.6028/NIST.SP.800-53r4<br /> # Joint Technical Committee 1, ''Information Technology'', Subcommittee 27, ''IT Security Techniques''. ''Information Technology - Security Techniques - Information Security Management Systems - Overview and Vocabulary''. ISO/IEC. (2014). http://standards.iso.org/ittf/PubliclyAvailableStandards/c063411_ISO_IEC_27000_2014.zip<br /> # ''The Standard of Good Practice for Information Security''. Information Security Forum. (2014). https://www.securityforum.org/shop/p-71-173<br /> # DSS05 within ''Cobit 5: Enabling Processes''. ISACA. (2012). http://www.isaca.org/COBIT/Pages/COBIT-5-Enabling-Processes-product-page.aspx<br /> # OWASP [[Access Control Cheat Sheet]]<br /> # OWASP [[Guide to Authorization]]<br /> <br /> [[Category:Control]]<br /> <br /> [[Category:Countermeasure]]<br /> <br /> [[Category:Access_Control]]</div>

MelDrews https://wiki.owasp.org/index.php?title=Authorization&diff=195179 2015-05-23T17:05:00Z

<p>MelDrews: Formatting</p> <hr /> <div>= Authorization / Access Control: =<br /> This article focuses on the authorization aspect of access controls as they are reflected in software designs, implementations and the management of software development lifecycles. Some sources include both authentication and authorization as aspects of access control. These are closely related but separate concepts and are managed through different processes.<br /> <br /> <br /> ISO 27000:2014 defines access control as meaning to ensure that access to assets is authorized and restricted based on business and security requirements.<br /> <br /> <br /> The definitions of access control provided in U.S. National Institute of Standards and Technology (NIST) Special Publication 800-53 (SP800-53) are context specific and not given a general definition. We do find, however, that the Access Control family of controls focuses on both authentication and authorization.<br /> <br /> <br /> The Information Security Forum Standard of Good Practice (2014) includes Access Control and User Authorization as separate controls within the Access Management control group. Authorization privileges are discussed there in Access Control (CF6.1.6), among others.<br /> <br /> <br /> All of these standards are frequently referenced sources of good guidance on access controls.<br /> <br /> == Definitions: ==<br /> Based on the guidance of such standards and common usage in the field, the following definitions are proposed:<br /> <br /> <br /> Authorization controls govern decisions and processes of determining, documenting and managing the subjects (users, devices or processes) that should be granted access and the objects to which they should be granted access; essentially, what is allowed.<br /> <br /> <br /> Access controls govern the methods and conditions of enforcement by which subjects (users, devices or processes) are allowed to or restricted from connecting with, viewing, consuming, entering into or making use of identified information resources (objects). <br /> <br /> == Some Generic Types of Access Controls: ==<br /> When thinking of access control, you might first think of the ability to login to a system or access files or a database. Access can be controlled, however, at various levels and with respect to a wide range of subjects and objects. Some examples include:<br /> <br /> <br /> * Network access - the ability to connect to a system or service;<br /> * At the host - access to operating system functionality;<br /> * Physical access - at locations housing information assets or physical access to the assets themselves;<br /> * Restricted functions - operations evaluated as having an elevated risk, such as financial transactions, changes to system configuration, or security administration.<br /> <br /> Resource access may refer not only to files and database functionality, but to:<br /> <br /> * applications or APIs;<br /> * specific application screens or functions;<br /> * specific data fields;<br /> * memory;<br /> * private or protected variables;<br /> * storage media;<br /> * transmission media;<br /> * In short, any object used in processing, storage or transmission of information.<br /> <br /> == Access Control Models: ==<br /> '''Discretionary access controls''' are based on the identity and need-to-know of subjects and/or the groups to which they belong. They are discretionary in the sense that a subject with certain access permissions is capable of passing on that access, directly or indirectly, to other subjects.<br /> <br /> <br /> '''Mandatory access controls''' are based on the sensitivity of the information contained in the objects / resources and a formal authorization. They are mandatory in the sense that they restrain subjects from setting security attributes on an object and from passing on their access.<br /> <br /> <br /> '''Role-based access controls (RBAC)''' are based on the roles played by users and groups in organizational functions. Roles, alternatively referred to as security groups, include collections of subjects that all share common needs for access. Authorization for access is then provided to the role or group and inherited by members.<br /> <br /> <br /> '''Attribute-based access control (ABAC)''' is a newer paradigm based on properties of an information exchange that may include identified attributes of the requesting entity, the resource requested, or the context of the exchange or the requested action. Some examples of contextual attributes are things such as:<br /> <br /> * time of day;<br /> * location;<br /> * currently evaluated threat level;<br /> * required hygiene measures implemented on the respective hosts.<br /> <br /> In general, in ABAC, a rules engine evaluates the identified attributes to issue an authorization decision.<br /> <br /> == Examples of Access Controls in Software: ==<br /> * Mapping of user rights to business and process requirements;<br /> * Mechanisms that enforce policies over information flow;<br /> * Limits on the number of concurrent sessions;<br /> * Session lock after a period of inactivity;<br /> * Session termination after a period of inactivity, total time of use or time of day;<br /> * Limitations on the number of records returned from a query (data mining);<br /> * Features enforcing policies over segregation of duties;<br /> * Segregation and management of privileged user accounts;<br /> * Implementation of the principle of least privilege for granting access;<br /> * Requiring VPN (virtual private network) for access;<br /> * Dynamic reconfiguration of user interfaces based on authorization;<br /> * Restriction of access after a certain time of day.<br /> <br /> == Related resources: ==<br /> # Joint Task Force Transformation Initiative. ''Security and Privacy Controls for Federal Information Systems and Organizations''. Special Publication 800-53 revision 4. (2013) U.S. National Institute of Standards and Technology. http://dx.doi.org/10.6028/NIST.SP.800-53r4<br /> # Joint Technical Committee 1, ''Information Technology'', Subcommittee 27, ''IT Security Techniques''. ''Information Technology - Security Techniques - Information Security Management Systems - Overview and Vocabulary''. ISO/IEC. (2014). http://standards.iso.org/ittf/PubliclyAvailableStandards/c063411_ISO_IEC_27000_2014.zip<br /> # ''The Standard of Good Practice for Information Security''. Information Security Forum. (2014). https://www.securityforum.org/shop/p-71-173<br /> # DSS05 within ''Cobit 5: Enabling Processes''. ISACA. (2012). http://www.isaca.org/COBIT/Pages/COBIT-5-Enabling-Processes-product-page.aspx<br /> # OWASP [[Access Control Cheat Sheet]]<br /> # OWASP [[Guide to Authorization]]<br /> <br /> [[Category:Control]]<br /> <br /> [[Category:Countermeasure]]<br /> <br /> [[Category:Access_Control]]</div>

MelDrews https://wiki.owasp.org/index.php?title=Authorization&diff=195178 2015-05-23T17:03:40Z

<p>MelDrews: Undo revision 195177 by MelDrews (talk)</p> <hr /> <div>= Authorization / Access Control: =<br /> This article focuses on the authorization aspect of access controls as they are reflected in software designs, implementations and the management of software development lifecycles. Some sources include both authentication and authorization as aspects of access control. These are closely related but separate concepts and are managed through different processes.<br /> <br /> <br /> ISO 27000:2014 defines access control as meaning to ensure that access to assets is authorized and restricted based on business and security requirements.<br /> <br /> <br /> The definitions of access control provided in U.S. National Institute of Standards and Technology (NIST) Special Publication 800-53 (SP800-53) are context specific and not given a general definition. We do find, however, that the Access Control family of controls focuses on both authentication and authorization.<br /> <br /> <br /> The Information Security Forum Standard of Good Practice (2014) includes Access Control and User Authorization as separate controls within the Access Management control group. Authorization privileges are discussed there in Access Control (CF6.1.6), among others.<br /> <br /> <br /> All of these standards are frequently referenced sources of good guidance on access controls.<br /> <br /> == Definitions: ==<br /> Based on the guidance of such standards and common usage in the field, the following definitions are proposed:<br /> <br /> <br /> Authorization controls govern decisions and processes of determining, documenting and managing the subjects (users, devices or processes) that should be granted access and the objects to which they should be granted access; essentially, what is allowed.<br /> <br /> <br /> Access controls govern the methods and conditions of enforcement by which subjects (users, devices or processes) are allowed to or restricted from connecting with, viewing, consuming, entering into or making use of identified information resources (objects). <br /> <br /> == Some Generic Types of Access Controls: ==<br /> When thinking of access control, you might first think of the ability to login to a system or access files or a database. Access can be controlled, however, at various levels and with respect to a wide range of subjects and objects. Some examples include:<br /> <br /> <br /> * Network access - the ability to connect to a system or service;<br /> * At the host - access to operating system functionality;<br /> * Physical access - at locations housing information assets or physical access to the assets themselves;<br /> * Restricted functions - operations evaluated as having an elevated risk, such as financial transactions, changes to system configuration, or security administration.<br /> <br /> Resource access may refer not only to files and database functionality, but to:<br /> <br /> * applications or APIs;<br /> * specific application screens or functions;<br /> * specific data fields;<br /> * memory;<br /> * private or protected variables;<br /> * storage media;<br /> * transmission media;<br /> * In short, any object used in processing, storage or transmission of information.<br /> <br /> == Access Control Models: ==<br /> Discretionary access controls are based on the identity and need-to-know of subjects and/or the groups to which they belong. They are discretionary in the sense that a subject with certain access permissions is capable of passing on that access, directly or indirectly, to other subjects.<br /> <br /> <br /> Mandatory access controls are based on the sensitivity of the information contained in the objects / resources and a formal authorization. They are mandatory in the sense that they restrain subjects from setting security attributes on an object and from passing on their access.<br /> <br /> <br /> Role-based access controls (RBAC) are based on the roles played by users and groups in organizational functions. Roles, alternatively referred to as security groups, include collections of subjects that all share common needs for access. Authorization for access is then provided to the role or group and inherited by members.<br /> <br /> <br /> Attribute-based access control (ABAC) is a newer paradigm based on properties of an information exchange that may include identified attributes of the requesting entity, the resource requested, or the context of the exchange or the requested action. Some examples of contextual attributes are things such as:<br /> <br /> * time of day;<br /> * location;<br /> * currently evaluated threat level;<br /> * required hygiene measures implemented on the respective hosts.<br /> <br /> In general, in ABAC, a rules engine evaluates the identified attributes to issue an authorization decision.<br /> <br /> == Examples of Access Controls in Software: ==<br /> * Mapping of user rights to business and process requirements;<br /> * Mechanisms that enforce policies over information flow;<br /> * Limits on the number of concurrent sessions;<br /> * Session lock after a period of inactivity;<br /> * Session termination after a period of inactivity, total time of use or time of day;<br /> * Limitations on the number of records returned from a query (data mining);<br /> * Features enforcing policies over segregation of duties;<br /> * Segregation and management of privileged user accounts;<br /> * Implementation of the principle of least privilege for granting access;<br /> * Requiring VPN (virtual private network) for access;<br /> * Dynamic reconfiguration of user interfaces based on authorization;<br /> * Restriction of access after a certain time of day.<br /> <br /> == Related resources: ==<br /> # Joint Task Force Transformation Initiative. ''Security and Privacy Controls for Federal Information Systems and Organizations''. Special Publication 800-53 revision 4. (2013) U.S. National Institute of Standards and Technology. http://dx.doi.org/10.6028/NIST.SP.800-53r4<br /> # Joint Technical Committee 1, ''Information Technology'', Subcommittee 27, ''IT Security Techniques''. ''Information Technology - Security Techniques - Information Security Management Systems - Overview and Vocabulary''. ISO/IEC. (2014). http://standards.iso.org/ittf/PubliclyAvailableStandards/c063411_ISO_IEC_27000_2014.zip<br /> # ''The Standard of Good Practice for Information Security''. Information Security Forum. (2014). https://www.securityforum.org/shop/p-71-173<br /> # DSS05 within ''Cobit 5: Enabling Processes''. ISACA. (2012). http://www.isaca.org/COBIT/Pages/COBIT-5-Enabling-Processes-product-page.aspx<br /> # OWASP [[Access Control Cheat Sheet]]<br /> # OWASP [[Guide to Authorization]]<br /> <br /> [[Category:Control]]<br /> <br /> [[Category:Countermeasure]]<br /> <br /> [[Category:Access_Control]]</div>

MelDrews https://wiki.owasp.org/index.php?title=Authorization&diff=195177 2015-05-23T17:02:46Z

<p>MelDrews: Formatting</p> <hr /> <div><br /> = Authorization / Access Control: =<br /> This article focuses on the authorization aspect of access controls as they are reflected in software designs, implementations and the management of software development lifecycles. Some sources include both authentication and authorization as aspects of access control. These are closely related but separate concepts and are managed through different processes.<br /> <br /> ISO 27000:2014 defines access control as meaning to ensure that access to assets is authorized and restricted based on business and security requirements.<br /> <br /> The definitions of access control provided in U.S. National Institute of Standards and Technology (NIST) Special Publication 800-53 (SP800-53) are context specific and not given a general definition. We do find, however, that the Access Control family of controls focuses on both authentication and authorization.<br /> <br /> The Information Security Forum Standard of Good Practice (2014) includes Access Control and User Authorization as separate controls within the Access Management control group. Authorization privileges are discussed there in Access Control (CF6.1.6), among others.<br /> <br /> All of these standards are frequently referenced sources of good guidance on access controls.<br /> <br /> == Definitions: ==<br /> Based on the guidance of such standards and common usage in the field, the following definitions are proposed:<br /> <br /> Authorization controls govern decisions and processes of determining, documenting and managing the subjects (users, devices or processes) that should be granted access and the objects to which they should be granted access; essentially, what is allowed.<br /> <br /> Access controls govern the methods and conditions of enforcement by which subjects (users, devices or processes) are allowed to or restricted from connecting with, viewing, consuming, entering into or making use of identified information resources (objects). <br /> <br /> == Some Generic Types of Access Controls: ==<br /> When thinking of access control, you might first think of the ability to login to a system or access files or a database. Access can be controlled, however, at various levels and with respect to a wide range of subjects and objects. Some examples include:<br /> <br /> * Network access - the ability to connect to a system or service;<br /> * At the host - access to operating system functionality;<br /> * Physical access - at locations housing information assets or physical access to the assets themselves;<br /> * Restricted functions - operations evaluated as having an elevated risk, such as financial transactions, changes to system configuration, or security administration.<br /> <br /> Resource access may refer not only to files and database functionality, but to:<br /> <br /> * applications or APIs;<br /> * specific application screens or functions;<br /> * specific data fields;<br /> * memory;<br /> * private or protected variables;<br /> * storage media;<br /> * transmission media;<br /> * In short, any object used in processing, storage or transmission of information.<br /> <br /> == Access Control Models: ==<br /> '''Discretionary access controls''' are based on the identity and need-to-know of subjects and/or the groups to which they belong. They are discretionary in the sense that a subject with certain access permissions is capable of passing on that access, directly or indirectly, to other subjects.<br /> <br /> '''Mandatory access controls''' are based on the sensitivity of the information contained in the objects / resources and a formal authorization. They are mandatory in the sense that they restrain subjects from setting security attributes on an object and from passing on their access.<br /> <br /> '''Role-based access controls (RBAC)''' are based on the roles played by users and groups in organizational functions. Roles, alternatively referred to as security groups, include collections of subjects that all share common needs for access. Authorization for access is then provided to the role or group and inherited by members.<br /> <br /> '''Attribute-based access control (ABAC)''' is a newer paradigm based on properties of an information exchange that may include identified attributes of the requesting entity, the resource requested, or the context of the exchange or the requested action. Some examples of contextual attributes are things such as:<br /> <br /> * time of day;<br /> * location;<br /> * currently evaluated threat level;<br /> * required hygiene measures implemented on the respective hosts.<br /> <br /> In general, in ABAC, a rules engine evaluates the identified attributes to issue an authorization decision.<br /> <br /> == Examples of Access Controls in Software: ==<br /> * Mapping of user rights to business and process requirements;<br /> * Mechanisms that enforce policies over information flow;<br /> * Limits on the number of concurrent sessions;<br /> * Session lock after a period of inactivity;<br /> * Session termination after a period of inactivity, total time of use or time of day;<br /> * Limitations on the number of records returned from a query (data mining);<br /> * Features enforcing policies over segregation of duties;<br /> * Segregation and management of privileged user accounts;<br /> * Implementation of the principle of least privilege for granting access;<br /> * Requiring VPN (virtual private network) for access;<br /> * Dynamic reconfiguration of user interfaces based on authorization;<br /> * Restriction of access after a certain time of day.<br /> <br /> == Related resources: ==<br /> # Joint Task Force Transformation Initiative. ''Security and Privacy Controls for Federal Information Systems and Organizations''. Special Publication 800-53 revision 4. (2013) U.S. National Institute of Standards and Technology. http://dx.doi.org/10.6028/NIST.SP.800-53r4<br /> # Joint Technical Committee 1, ''Information Technology'', Subcommittee 27, ''IT Security Techniques''. ''Information Technology - Security Techniques - Information Security Management Systems - Overview and Vocabulary''. ISO/IEC. (2014). http://standards.iso.org/ittf/PubliclyAvailableStandards/c063411_ISO_IEC_27000_2014.zip<br /> # ''The Standard of Good Practice for Information Security''. Information Security Forum. (2014). https://www.securityforum.org/shop/p-71-173<br /> # DSS05 within ''Cobit 5: Enabling Processes''. ISACA. (2012). http://www.isaca.org/COBIT/Pages/COBIT-5-Enabling-Processes-product-page.aspx<br /> # OWASP [[Access Control Cheat Sheet]]<br /> # OWASP [[Guide to Authorization]]<br /> <br /> [[Category:Control]]<br /> <br /> [[Category:Countermeasure]]<br /> <br /> [[Category:Access_Control]]</div>

MelDrews https://wiki.owasp.org/index.php?title=Authorization&diff=195176 2015-05-23T16:56:54Z

<p>MelDrews: Removed stub template. Added definitions, examples and references</p> <hr /> <div>= Authorization / Access Control: =<br /> This article focuses on the authorization aspect of access controls as they are reflected in software designs, implementations and the management of software development lifecycles. Some sources include both authentication and authorization as aspects of access control. These are closely related but separate concepts and are managed through different processes.<br /> <br /> <br /> ISO 27000:2014 defines access control as meaning to ensure that access to assets is authorized and restricted based on business and security requirements.<br /> <br /> <br /> The definitions of access control provided in U.S. National Institute of Standards and Technology (NIST) Special Publication 800-53 (SP800-53) are context specific and not given a general definition. We do find, however, that the Access Control family of controls focuses on both authentication and authorization.<br /> <br /> <br /> The Information Security Forum Standard of Good Practice (2014) includes Access Control and User Authorization as separate controls within the Access Management control group. Authorization privileges are discussed there in Access Control (CF6.1.6), among others.<br /> <br /> <br /> All of these standards are frequently referenced sources of good guidance on access controls.<br /> <br /> == Definitions: ==<br /> Based on the guidance of such standards and common usage in the field, the following definitions are proposed:<br /> <br /> <br /> Authorization controls govern decisions and processes of determining, documenting and managing the subjects (users, devices or processes) that should be granted access and the objects to which they should be granted access; essentially, what is allowed.<br /> <br /> <br /> Access controls govern the methods and conditions of enforcement by which subjects (users, devices or processes) are allowed to or restricted from connecting with, viewing, consuming, entering into or making use of identified information resources (objects). <br /> <br /> == Some Generic Types of Access Controls: ==<br /> When thinking of access control, you might first think of the ability to login to a system or access files or a database. Access can be controlled, however, at various levels and with respect to a wide range of subjects and objects. Some examples include:<br /> <br /> <br /> * Network access - the ability to connect to a system or service;<br /> * At the host - access to operating system functionality;<br /> * Physical access - at locations housing information assets or physical access to the assets themselves;<br /> * Restricted functions - operations evaluated as having an elevated risk, such as financial transactions, changes to system configuration, or security administration.<br /> <br /> Resource access may refer not only to files and database functionality, but to:<br /> <br /> * applications or APIs;<br /> * specific application screens or functions;<br /> * specific data fields;<br /> * memory;<br /> * private or protected variables;<br /> * storage media;<br /> * transmission media;<br /> * In short, any object used in processing, storage or transmission of information.<br /> <br /> == Access Control Models: ==<br /> Discretionary access controls are based on the identity and need-to-know of subjects and/or the groups to which they belong. They are discretionary in the sense that a subject with certain access permissions is capable of passing on that access, directly or indirectly, to other subjects.<br /> <br /> <br /> Mandatory access controls are based on the sensitivity of the information contained in the objects / resources and a formal authorization. They are mandatory in the sense that they restrain subjects from setting security attributes on an object and from passing on their access.<br /> <br /> <br /> Role-based access controls (RBAC) are based on the roles played by users and groups in organizational functions. Roles, alternatively referred to as security groups, include collections of subjects that all share common needs for access. Authorization for access is then provided to the role or group and inherited by members.<br /> <br /> <br /> Attribute-based access control (ABAC) is a newer paradigm based on properties of an information exchange that may include identified attributes of the requesting entity, the resource requested, or the context of the exchange or the requested action. Some examples of contextual attributes are things such as:<br /> <br /> * time of day;<br /> * location;<br /> * currently evaluated threat level;<br /> * required hygiene measures implemented on the respective hosts.<br /> <br /> In general, in ABAC, a rules engine evaluates the identified attributes to issue an authorization decision.<br /> <br /> == Examples of Access Controls in Software: ==<br /> * Mapping of user rights to business and process requirements;<br /> * Mechanisms that enforce policies over information flow;<br /> * Limits on the number of concurrent sessions;<br /> * Session lock after a period of inactivity;<br /> * Session termination after a period of inactivity, total time of use or time of day;<br /> * Limitations on the number of records returned from a query (data mining);<br /> * Features enforcing policies over segregation of duties;<br /> * Segregation and management of privileged user accounts;<br /> * Implementation of the principle of least privilege for granting access;<br /> * Requiring VPN (virtual private network) for access;<br /> * Dynamic reconfiguration of user interfaces based on authorization;<br /> * Restriction of access after a certain time of day.<br /> <br /> == Related resources: ==<br /> # Joint Task Force Transformation Initiative. ''Security and Privacy Controls for Federal Information Systems and Organizations''. Special Publication 800-53 revision 4. (2013) U.S. National Institute of Standards and Technology. http://dx.doi.org/10.6028/NIST.SP.800-53r4<br /> # Joint Technical Committee 1, ''Information Technology'', Subcommittee 27, ''IT Security Techniques''. ''Information Technology - Security Techniques - Information Security Management Systems - Overview and Vocabulary''. ISO/IEC. (2014). http://standards.iso.org/ittf/PubliclyAvailableStandards/c063411_ISO_IEC_27000_2014.zip<br /> # ''The Standard of Good Practice for Information Security''. Information Security Forum. (2014). https://www.securityforum.org/shop/p-71-173<br /> # DSS05 within ''Cobit 5: Enabling Processes''. ISACA. (2012). http://www.isaca.org/COBIT/Pages/COBIT-5-Enabling-Processes-product-page.aspx<br /> # OWASP [[Access Control Cheat Sheet]]<br /> # OWASP [[Guide to Authorization]]<br /> <br /> [[Category:Control]]<br /> <br /> [[Category:Countermeasure]]<br /> <br /> [[Category:Access_Control]]</div>

MelDrews