[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [was] Notes on WAS Face to Face
Yuval, Thanks for the reminder. Everyone else, rest assured that we your comments will be taken into account and you'll see them reflected in the schema definition as it evolves. Mark, was there a plan where to take article type definition from? Peter -----Original Message----- From: Yuval Ben-Itzhak [mailto:yuvalben@netvision.net.il] Sent: Thursday, April 01, 2004 9:18 AM To: Peter Michalek Subject: RE: [was] Notes on WAS Face to Face Peter, The type "article" was not define in the schema. <xsd:element name="article" type="article"/> Yuval. -----Original Message----- From: Peter Michalek [mailto:peter@fortifysoftware.com] Sent: Thursday, April 01, 2004 3:47 PM To: 'Jeff Williams'; 'Mark Curphey'; 'David Raphael' Cc: was@lists.oasis-open.org Subject: RE: [was] Notes on WAS Face to Face Jeff, thanks for detail annotation notes, I incorporated them into the document and as you suggested, deleted this: <xsd:enumeration value="Injection.OS"/> FIXME: THIS IS A DUPLICATE of Injection.OSCommand and should be deleted. I also added BufferOverflow "super-category" that was missing. I didn't some minor changes in your wording of some, e.g. IntegerOverflow Modified .xsd and diff to the previous version are attached. Peter -----Original Message----- From: Jeff Williams [mailto:jeff.williams@aspectsecurity.com] Sent: Wednesday, March 31, 2004 8:49 PM To: Peter Michalek; 'Mark Curphey'; 'David Raphael' Cc: was@lists.oasis-open.org Subject: Re: [was] Notes on WAS Face to Face Here are some updated definitions. I'm not sure the syntax for annotations -- is it right to just have one big block for the whole list? Or should there be a separate annotation for each item in the list? ------------- <xsd:enumeration value="AccessControl"/> Used for problems that allow users to access assets or functions they are not authorized for. Frequently, there is no access control mechanism where there should be. A proper access control mechanism should enforce the principles of a reference monitor: non-bypassable, tamperproof, and analyzable. <xsd:enumeration value="ConfigurationManagement"/> Used to describe problems in the configuration of an application or application environment. <xsd:enumeration value="ConfigurationManagement.Administration"/> Used for problems in the application's mechanisms that enable remote administration, such as user management, credential management, database management, and other configuration options. <xsd:enumeration value="ConfigurationManagement.Application"/> Used to describe problems in the application's configuration, such as misconfigured security mechanisms, default programs, unused code, and unnecessarily enabled features. <xsd:enumeration value="ConfigurationManagement.Infrastructure"/> Used for problems with the configuration of the application's infrastructure, such as the web and application servers, filters, and external security mechanisms. <xsd:enumeration value="IntegerOverflow"/> Used for problems resulting from attempts to put a large number into a variable too small to hold it. This can occur when parsing problems occur or mathematical functions are misused. These errors are particularly dangerous when the overflowed variable is used to allocate memory. <xsd:enumeration value="DataProtection"/> Used for issues related to inappropriate disclosure of data. <xsd:enumeration value="DataProtection.Storage"/> Used for problems storing data securely, including storage of credentials, keys, and other sensitive information. Mistakes related to cryptographic mechanisms are examples, including poor sources of randomness, bad choice of algorithm, and poor implementation. <xsd:enumeration value="DataProtection.Transport"/> Used for problems related to secure transfer of information. Frequently, this will refer to problems with SSL or TLS configuration, but could include other protocols with security features. <xsd:enumeration value="InputValidation"/> Used for issues related to failure to validate untrusted input before it is relied on by an application. <xsd:enumeration value="InputValidation.User"/> Used for input validation problems where the input comes from a human user, such as HTTP request parameters, command line input, or input events from an application's GUI. <xsd:enumeration value="InputValidation.Network"/> Used for input validation problems where the input comes from a network protocol, such as HTTP headers, sequence numbers, or other protocol fields. <xsd:enumeration value="InputValidation.File"/> Used for input validation problems where the input comes from a file, such as a properties file, batch data file, flat-file databases, or other file based data. <xsd:enumeration value="Concurrency"/> Used for errors in multithreaded environments that allow data to be shared or corrupted. Examples include variables that are shared between threads and cause time-of-check-time-of-use (TOCTOU) problems, broken singleton patterns, and poor cache design. <xsd:enumeration value="AppDOS"/> Used for flaws that would allow an attacker to completely or partially prevent users from using an application properly. <xsd:enumeration value="AppDOS.Flood"/> Used for application denial of service problems that involve saturating some limited resource shared by all users of the application, such as disk space, CPU, network bandwidth, database connections, or memory. <xsd:enumeration value="AppDOS.Lockout"/> Used for application denial of service problems that involve using up some resource that is allocated to a user of the application, such as failed logon attempts, minutes, messages, or transactions. <xsd:enumeration value="BufferOverflow.Heap"/> Used for flaws that allow an attacker to overflow memory that is dynamically allocated by the application. <xsd:enumeration value="BufferOverflow.Stack"/> Used for flaws that allow an attacker to write data into the stack, causing the program to crash or transfer control. <xsd:enumeration value="BufferOverflow.Format"/> Used for flaws that allow an attacker to use format strings to overwrite locations in memory, allowing data to be changed, program control to be altered, or the program to crash. <xsd:enumeration value="Injection"/> Used for problems that allow an attacker to bury commands into data and have them interpreted by some system that the data reaches. <xsd:enumeration value="Injection.OS"/> FIXME: THIS IS A DUPLICATE of Injection.OSCommand and should be deleted. <xsd:enumeration value="Injection.SQL"/> Used for flaws that allow an attacker to inject special characters and commands into a SQL database and modify the intended query. The attack might attempt to change the meaning of the query, or might attempt to chain additional commands. <xsd:enumeration value="Injection.HTML"/> Used for flaws that allow an attacker to inject HTML into an application and modify the appearance of HTML generated by that application. For example, an attacker might inject an unwanted IMG tag into a guest book, and offend other users. <xsd:enumeration value="Injection.OSCommand"/> Used for flaws that allow an attacker to inject special characters and commands into the operating system command shell and modify the intended command. The attack might attempt to modify how a program is invoked, or might attempt to chain additional commands. <xsd:enumeration value="Injection.LDAP"/> Used for flaws that allow an attacker to inject special characters and search terms into an LDAP server and modify the intended query. <xsd:enumeration value="Injection.XSS"/> Used for flaws that allow an attacker to send malicious scripts through a web application and have them execute on victims' browsers. Stored XSS attacks involve storing the script in the web application for users to find. Reflected XSS attacks are bounced off a web application in real time and require a user to be tricked into sending the request containing the attack. <xsd:enumeration value="ErrorHandling"/> Used for problems in handling errors, including printing stack traces to the screen, fail open security mechanisms, allowing errors to affect the operation of the entire application, and revealing too much information about a failure. <xsd:enumeration value="Monitoring"/> Used for issues related to monitoring the security posture of a web application. <xsd:enumeration value="Monitoring.Logging"/> Used for issues concerning the proper logging of events, including what should be logged, how it should be logged, how logs should be reviewed, and other issues related to accountability. <xsd:enumeration value="Monitoring.Detection"/> Used for issues related to the detection of attacks on an application, how attacks should be handled, what information should be gathered, and who should be notified. <xsd:enumeration value="Cryptography"/> Used for problems related to encryption, decryption, signing, and verification. <xsd:enumeration value="Cryptography.Algorithm"/> Used for cryptographic algorithm selection, implementation, and analysis problems. <xsd:enumeration value="Cryptography.KeyManagement"/> Used for issues with certificate storage, tokens, revocation, certificates, key stores, issuing keys, and other key issues ;-) <xsd:enumeration value="Authentication"/> Used for problems related to determining the identity of individuals and authenticating that identity. <xsd:enumeration value="Authentication.User"/> Used for issues related to identification and authentication of people who are intended to use an application. Problems with usernames, passwords, tokens, smartcards, biometrics, and other credentials are examples. <xsd:enumeration value="Authentication.UserManagement"/> Used for problems related to managing a set of users, especially the security relevant information such as roles, privileges, authorizations, groups, social security numbers, credit card numbers, and other sensitive information. Also problems with creating new users, registration, granting rights, and terminating access. <xsd:enumeration value="Authentication.Entity"/> Used for problems with authenticating automated systems, such as web services, databases, directories, and others. Examples include secure credential storage, securing transport, changing credentials, and terminating access. <xsd:enumeration value="Authentication.SessionManagement"/> Used for problems with issuing, using, protecting, changing, and terminating session identifiers of all kinds. Session identifiers stand in the place of authentication credentials yet are freqently not protected as carefully. --Jeff ----- Original Message ----- From: Peter Michalek To: 'Mark Curphey' ; 'David Raphael' Cc: was@lists.oasis-open.org Sent: Wednesday, March 31, 2004 8:56 PM Subject: RE: [was] Notes on WAS Face to Face Mark, Attached is a (phase I) modification of the schema that we created at the face to face meeting and also diffs with this baseline: http://www.oasis-open.org/apps/org/workgroup/was/download.php/6134/oasis-was -version4.xsd This modification contains mainly new annotations for vulnTypes, also including the wording/explanation of why it's a collection (see previous email from Jeff Williams). Please see: 1) See: Line 38 - definition of Ids - how to we make them globally unique. 2) Line 308 - vulnList, vulnTypes - first attempt at documenting them, I think it needs more work, ideally with references to papers to make sure everyone understands the background behind each type. I didn't address any of the issues raised in other emails for now. I also think the suggestion to put this under version control is a good one, and will make it easier to evolve the schema into the final form. David, if you decide to do it, you can check this in. Peter -----Original Message----- From: Mark Curphey [mailto:mark.curphey@foundstone.com] Sent: Monday, March 29, 2004 10:44 AM To: Peter Michalek Cc: was@lists.oasis-open.org Subject: RE: [was] Notes on WAS Face to Face Peter, Feel free to clean up what you need to. Some of the older vuln info is still there and the original info of Attack Types etc from the older risk ranking model. I think we should take that out. Also what do you think about a structure of WAS Core.xsd that calls WAS Detect WAS Protect This allows for an easier development (less merge conflicts) but would also allow us to increment sub-elements moving forward without having to update the entire schema. Mark As a note Symantec will be joining WAS in an active role this week! -----Original Message----- From: Peter Michalek [mailto:peter@fortifysoftware.com] Sent: Monday, March 29, 2004 11:49 AM To: Mark Curphey Subject: RE: [was] Notes on WAS Face to Face Hi Mark, This is a good summary of vulnTypes that is useful, how we need to clean up and publishing as schema so that it has a more professional look. If you would be OK with that, we could go ahead with my proposal from Saturday and clean up and relatively finalize the stuff we came up with last week. You probably want to do it at your own pace and coordinate with other things, which is fine. Just let me know when you are ready. Peter -----Original Message----- From: Mark Curphey [mailto:mark.curphey@foundstone.com] Sent: Sunday, March 28, 2004 6:10 PM To: was@lists.oasis-open.org Subject: [was] Notes on WAS Face to Face As you will know from the notifications I have uploaded the meeting minutes from last weeks face to face and the updated working schema. It was a great meeting and we are making real progress. I am fairly confident we can publish the drafts of meta-data and profile as well the supporting documents before the end of April. The supporting documents will be; OASIS WAS Thesaurus (using VulnTypes) - this is the classification scheme OASIS WAS Vision Document OASIS WAS Core Schema Documented For those who don't read the minutes or look at the schema, I think some of the important schema is below. This will allow for rich metrics and measurement programs to be created by using the categories. <xsd:simpleType name="vulnList"> <xsd:restriction base="xsd:string"> <xsd:enumeration value="AccessControl" /> <xsd:enumeration value="ConfigurationManagement" /> <xsd:enumeration value="ConfigurationManagement.Administration" /> <xsd:enumeration value="ConfigurationManagement.Application" /> <xsd:enumeration value="ConfigurationManagement.Infrastructure" /> <xsd:enumeration value="IntegerOverflow" /> <xsd:enumeration value="DataProtection" /> <xsd:enumeration value="DataProtection.Storage" /> <xsd:enumeration value="DataProtection.Transport" /> <xsd:enumeration value="InputValidation" /> <xsd:enumeration value="InputValidation.User" /> <xsd:enumeration value="InputValidation.Network" /> <xsd:enumeration value="InputValidation.File" /> <xsd:enumeration value="Concurrency" /> <xsd:enumeration value="AppDOS" /> <xsd:enumeration value="AppDOS.Flood" /> <xsd:enumeration value="AppDOS.Lockout" /> <xsd:enumeration value="BufferOverflow.Heap" /> <xsd:enumeration value="BufferOverflow.Stack" /> <xsd:enumeration value="BufferOverflow.Format" /> <xsd:enumeration value="Injection" /> <xsd:enumeration value="Injection.OS" /> <xsd:enumeration value="Injection.SQL" /> <xsd:enumeration value="Injection.HTML" /> <xsd:enumeration value="Injection.OSCommand" /> <xsd:enumeration value="Injection.LDAP" /> <xsd:enumeration value="Injection.XSS" /> <xsd:enumeration value="ErrorHandling" /> <xsd:enumeration value="Monitoring" /> <xsd:enumeration value="Monitoring.Logging" /> <xsd:enumeration value="Monitoring.Detection" /> <xsd:enumeration value="Cryptography" /> <xsd:enumeration value="Cryptography.Algorithm" /> <xsd:enumeration value="Cryptography.KeyManagement" /> <xsd:enumeration value="Authentication" /> <xsd:enumeration value="Authentication.User" /> <xsd:enumeration value="Authentication.UserManagement" /> <xsd:enumeration value="Authentication.Entity" /> <xsd:enumeration value="Authentication.SessionManagement" /> </xsd:restriction> </xsd:simpleType> <xsd:simpleType name="appType"> <xsd:restriction base="xsd:string"> <xsd:enumeration value="client-server" /> <xsd:enumeration value="web service" /> <xsd:enumeration value="standalone" /> <xsd:enumeration value="p2p" /> <xsd:enumeration value="web application" /> <xsd:enumeration value="server" /> <xsd:enumeration value="client" /> <xsd:enumeration value="mainframe" /> </xsd:restriction> </xsd:simpleType> <xsd:simpleType name="rootCauseType"> <xsd:restriction base="xsd:string"> <xsd:enumeration value="software defect" /> <xsd:enumeration value="config" /> </xsd:restriction> </xsd:simpleType> <xsd:simpleType name="RelatedProcesses"> <xsd:restriction base="xsd:string"> <xsd:enumeration value="RequirementsAnalysis" /> <xsd:enumeration value="DesignAnalysis" /> <xsd:enumeration value="code" /> <xsd:enumeration value="SecurityTesting" /> <xsd:enumeration value="Deployment" /> </xsd:restriction> </xsd:simpleType> </xsd:schema> Mark Curphey Consulting Director Foundstone, Inc. Strategic Security 949.297.5600 x2070 Tel 781.738.0857 Cell 949.297.5575 Fax http://www.foundstone.com This email may contain confidential and privileged information for the sole use of the intended recipient. Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies of this message. Thank you. To unsubscribe from this mailing list (and be removed from the roster of the OASIS TC), go to http://www.oasis-open.org/apps/org/workgroup/was/members/leave_workgroup .php . To unsubscribe from this mailing list (and be removed from the roster of the OASIS TC), go to http://www.oasis-open.org/apps/org/workgroup/was/members/leave_workgroup.php . To unsubscribe from this mailing list (and be removed from the roster of the OASIS TC), go to http://www.oasis-open.org/apps/org/workgroup/was/members/leave_workgroup.php .
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]