Loading ...
Sorry, an error occurred while loading the content.

Agile in Secure Software development

Expand Messages
  • bjoseph866
    Hey Guys, My company is interested in implementing Agile, but we can t seem to figure out how to also incorporate security software development. In essence, we
    Message 1 of 8 , Aug 20, 2014
    • 0 Attachment

       Hey Guys,

       

      My company is interested in implementing Agile, but we can't seem to figure out how to also incorporate security software development. In essence, we need some best practices on how to incorporate secure software development procedures into Agile.

    • schmonzie
      [List moderators: Even when I m quite sure my From: header matches my subscribed address, Yahoo tells me I m not subscribed and can t post. Pretty sure this
      Message 2 of 8 , Aug 20, 2014
      • 0 Attachment
        [List moderators: Even when I'm quite sure my From: header matches my subscribed address, Yahoo tells me I'm not subscribed and can't post. Pretty sure this used to work. Posting via the group's web interface now. Mail me me privately if you need more details.]

        On Wed, Aug 20, 2014 at 08:51:52AM -0700, bjoseph866@... [extremeprogramming] wrote:

        > My company is interested in implementing Agile, but we can't
        > seem to figure out how to also incorporate security software
        > development. In essence, we need some best practices on how to
        > incorporate secure software development procedures into Agile.

        Some handwavy, context-free thoughts:

        A design is secure iff it has accounted for all important functional
        and "non-functional" (hate that term) "requirements" (that one too)
        -- of which you can never be 100% sure.

        A security hole is a bug, avoidable in the same ways bugs are
        avoidable -- and equally incompletely avoidable.

        When mistakes of any kind (design, implementation, testing, etc.)
        are likely to have security implications, it's even more important
        to arrange for the work process to highlight mistakes ASAP.

        If you're relying on the team to make decisions which are likely
        to have security implications, you may want to offer training in
        the kind of practical knowledge and critical thinking required to
        make the decisions well.

        If your company can be sunk by one sufficiently bad security decision,
        you may want to involve security experts early and often in your
        development process. You may already be doing so!

        More context would help, if you can offer it. Which aspects of
        security is your company most concerned with? What practices and
        procedures have you been employing to address those concerns? How
        effective have they been? What now motivates the interest in Agile?

        - Amitai
      • George Dinwiddie
        On 8/20/14 12:43 PM, schmonz-web-yahoo@schmonz.com [extremeprogramming] ... Yes, many can be represented as User Stories. Other aspects can be treated the same
        Message 3 of 8 , Aug 20, 2014
        • 0 Attachment
          On 8/20/14 12:43 PM, schmonz-web-yahoo@... [extremeprogramming]
          wrote:
          > [List moderators: Even when I'm quite sure my From: header matches my subscribed address, Yahoo tells me I'm not subscribed and can't post. Pretty sure this used to work. Posting via the group's web interface now. Mail me me privately if you need more details.]
          >
          > On Wed, Aug 20, 2014 at 08:51:52AM -0700, bjoseph866@... [extremeprogramming] wrote:
          >
          >> My company is interested in implementing Agile, but we can't
          >> seem to figure out how to also incorporate security software
          >> development. In essence, we need some best practices on how to
          >> incorporate secure software development procedures into Agile.
          >
          > Some handwavy, context-free thoughts:
          >
          > A design is secure iff it has accounted for all important functional
          > and "non-functional" (hate that term) "requirements" (that one too)
          > -- of which you can never be 100% sure.
          >
          > A security hole is a bug, avoidable in the same ways bugs are
          > avoidable -- and equally incompletely avoidable.

          Yes, many can be represented as User Stories.

          Other aspects can be treated the same way as performance and usability
          testing, e.g., test early and often. Watch the trends over time.

          - George

          >
          > When mistakes of any kind (design, implementation, testing, etc.)
          > are likely to have security implications, it's even more important
          > to arrange for the work process to highlight mistakes ASAP.
          >
          > If you're relying on the team to make decisions which are likely
          > to have security implications, you may want to offer training in
          > the kind of practical knowledge and critical thinking required to
          > make the decisions well.
          >
          > If your company can be sunk by one sufficiently bad security decision,
          > you may want to involve security experts early and often in your
          > development process. You may already be doing so!
          >
          > More context would help, if you can offer it. Which aspects of
          > security is your company most concerned with? What practices and
          > procedures have you been employing to address those concerns? How
          > effective have they been? What now motivates the interest in Agile?
          >
          > - Amitai

          --
          ----------------------------------------------------------------------
          * George Dinwiddie * http://blog.gdinwiddie.com
          Software Development http://www.idiacomputing.com
          Consultant and Coach http://www.agilemaryland.org
          ----------------------------------------------------------------------
        • Keith Ray
          Some agile teams use Personas to represent their users and the different kinds of stories those users want. For security software, you may want to have one or
          Message 4 of 8 , Aug 20, 2014
          • 0 Attachment
            Some agile teams use Personas to represent their users and the different kinds of stories those users want. For security software, you may want to have one or more "black-hat" personas representing people who are trying to break the software.

            Stories for the black-hat should result in their failure to break in, and notifications (where appropriate) given to the user(s) responsible for the system's security.

            Story tests may include attempt to mimic DoS attacks, brute-force password guessing, and so on.

            Does this help?

            --
            C. Keith Ray
            * (650) 533-6535
            * Resume available on request. 




            On 2014 Aug 20, at 10:23 AM, George Dinwiddie lists@... [extremeprogramming] <extremeprogramming@yahoogroups.com> wrote:



            On 8/20/14 12:43 PM, schmonz-web-yahoo@... [extremeprogramming] 
            wrote:
            > [List moderators: Even when I'm quite sure my From: header matches my subscribed address, Yahoo tells me I'm not subscribed and can't post. Pretty sure this used to work. Posting via the group's web interface now. Mail me me privately if you need more details.]
            >
            > On Wed, Aug 20, 2014 at 08:51:52AM -0700, bjoseph866@... [extremeprogramming] wrote:
            >
            >> My company is interested in implementing Agile, but we can't
            >> seem to figure out how to also incorporate security software
            >> development. In essence, we need some best practices on how to
            >> incorporate secure software development procedures into Agile.
            >
            > Some handwavy, context-free thoughts:
            >
            > A design is secure iff it has accounted for all important functional
            > and "non-functional" (hate that term) "requirements" (that one too)
            > -- of which you can never be 100% sure.
            >
            > A security hole is a bug, avoidable in the same ways bugs are
            > avoidable -- and equally incompletely avoidable.

            Yes, many can be represented as User Stories.

            Other aspects can be treated the same way as performance and usability 
            testing, e.g., test early and often. Watch the trends over time.

            - George

            >
            > When mistakes of any kind (design, implementation, testing, etc.)
            > are likely to have security implications, it's even more important
            > to arrange for the work process to highlight mistakes ASAP.
            >
            > If you're relying on the team to make decisions which are likely
            > to have security implications, you may want to offer training in
            > the kind of practical knowledge and critical thinking required to
            > make the decisions well.
            >
            > If your company can be sunk by one sufficiently bad security decision,
            > you may want to involve security experts early and often in your
            > development process. You may already be doing so!
            >
            > More context would help, if you can offer it. Which aspects of
            > security is your company most concerned with? What practices and
            > procedures have you been employing to address those concerns? How
            > effective have they been? What now motivates the interest in Agile?
            >
            > - Amitai

            -- 
            ----------------------------------------------------------
            * George Dinwiddie * http://blog.gdinwiddie.com
            Software Development http://www.idiacomputing.com
            Consultant and Coach http://www.agilemaryland.org
            ----------------------------------------------------------


          • John Roth
            ... Are you talking about security requirements in application software, or software whose main function is some form of security? In both cases, I d suggest
            Message 5 of 8 , Aug 20, 2014
            • 0 Attachment
              On 8/20/14 9:51 AM, bjoseph866@... [extremeprogramming] wrote:
               

               Hey Guys,

               

              My company is interested in implementing Agile, but we can't seem to figure out how to also incorporate security software development. In essence, we need some best practices on how to incorporate secure software development procedures into Agile.


              Posted by: bjoseph866@...









              Are you talking about security requirements in application software, or software whose main function is some form of security?

              In both cases, I'd suggest automated functional testing. The Agile part is that the functional tests should be defined as part of fleshing out the story, not later, so they're there when the software is being constructed.

              As an example, last year there was a CVE against Python for a potential DOS attack gaming the hash function used in maps so it was linear time instead of log(n). From an application viewpoint, the testing tactic might be to test that only legitimate key-value pairs for the specific transaction are inserted into the map. This isn't something one would expect to fall out of the TDD loop; it needs to be specified.

              Here's a long-form article on unit testing in respect to the go-to-fail and heartbleed bugs. It's not specifically agile, but then agile doesn't prohibit writing other unit tests, it simply discourages doing it after the rest of the software is written. http://martinfowler.com/articles/testing-culture.html

              John Roth
            • bjoseph866
              I like the idea of the black-hat personas. It gives you a chance to see how secure the software really is, and seems fairly easy to implement into Agile.
              Message 6 of 8 , Aug 20, 2014
              • 0 Attachment
                I like the idea of the "black-hat" personas. It gives you a chance to see how secure the software really is, and seems fairly easy to implement into Agile.
              • Adam Sroka
                Depending on the application there could also be some white hat personas. e.g. stories related to alerting, preventing, diagnosing, etc. On Wed, Aug 20, 2014
                Message 7 of 8 , Aug 20, 2014
                • 0 Attachment
                  Depending on the application there could also be some "white hat" personas. e.g. stories related to alerting, preventing, diagnosing, etc. 


                  On Wed, Aug 20, 2014 at 1:54 PM, bjoseph866@... [extremeprogramming] <extremeprogramming@yahoogroups.com> wrote:
                   

                  I like the idea of the "black-hat" personas. It gives you a chance to see how secure the software really is, and seems fairly easy to implement into Agile.


                • daswartz@prodigy
                  If you haven t found it on OWASDP yet, you can find more information on the kind of stories that involve black-hat personas at:
                  Message 8 of 8 , Aug 20, 2014
                  • 0 Attachment
                    If you haven't found it on OWASDP yet, you can find more information
                    on the kind of stories that involve black-hat personas at:
                    https://www.owasp.org/index.php/Agile_Software_Development:_Don%27t_Forget_EVIL_User_Stories

                    Since most secure development life-cycle methodologies are focused on
                    doing activities in particular phases of the lifecycle, the Microsoft
                    doc on agile security can be useful to help get you thinking about
                    matching the security activities to the other activities we're doing
                    in agile software development. Like most other things in Agile
                    development, one of the keys to agility in developing secure software
                    effectively is to keep the feedback loop as short as possible.

                    For instance:

                    Every day we write code. Therefore, every day is a good time to run
                    static code security scans. If today there are more vulnerabilities
                    than there were yesterday, fixing those vulnerabilities is a priority
                    for today. If you can afford it, I believe Checkmarx is the most agile
                    friendly of the commercial static scanning tools. I don't work for
                    Checkmarx.

                    Coding standards reflecting secure coding practices are important. But
                    in XP we already value coding standards.

                    If you're using Scrum (Yes. I know this is an XP list :)), you do
                    backlog grooming. Backlog grooming is a good time to ask questions
                    about the possible security implications of the feature and make
                    security related design and testing notes about it. We won't do
                    threat assessment modeling during backlog grooming, but we'll note we need
                    to do one, or update the one we have. That will inform whatever
                    estimates we're making and stories we write. Release planning would be
                    a good time to do the same thing in XP.

                    On any decent sized system, dynamic application penetration scanning
                    can take quite a while. It also takes a somewhat skilled person to
                    make it useful. I would like to do it daily, like static scanning,
                    but that usually isn't practical. I do it monthly, or quarterly
                    depending on the system.

                    Manual security testing is the security equivalent of exploratory
                    functional testing. In fact, it is exploratory testing. But, it
                    requires a somewhat different mind set and skill set than functional
                    exploratory testing. While very valuable, if you're just getting
                    started with secure development practices, this is likely to be the
                    practice you implement last.

                    Which leads to skills. To be most effective at delivering solutions to
                    your customers, security skills need to be present in the
                    team, just like database skills and UI skills. Every developer can't
                    be a secure development expert. But, every developer should have an
                    understanding of the basics. Just like you probably have someone on
                    the team with deeper database skills, you need to have someone with
                    deeper secure development understanding.

                    HTH.

                    Doug Swartz

                    Wednesday, August 20, 2014, 12:44:04 PM, Keith Ray wrote:

                    > Some agile teams use Personas to represent their users and the
                    > different kinds of stories those users want. For security software,
                    > you may want to have one or more "black-hat" personas representing
                    > people who are trying to break the software.

                    > Stories for the black-hat should result in their failure to break
                    > in, and notifications (where appropriate) given to the user(s)
                    > responsible for the system's security.

                    > Story tests may include attempt to mimic DoS attacks, brute-force password guessing, and so on.

                    > Does this help?
                    >
                    > --
                    > C. Keith Ray
                    > * (650) 533-6535

                    > * Resume available on request.

                    > * http://agilesolutionspace.blogspot.com/
                    >
                    >

                    > On 2014 Aug 20, at 10:23 AM, George Dinwiddie
                    > lists@... [extremeprogramming]
                    > <extremeprogramming@yahoogroups.com> wrote:




                    > On 8/20/14 12:43 PM, schmonz-web-yahoo@... [extremeprogramming]
                    > wrote:
                    >> [List moderators: Even when I'm quite sure my From: header matches my subscribed address, Yahoo tells me I'm not subscribed and can't post. Pretty sure this used to work. Posting via the group's web interface now. Mail me me privately if you need more details.]
                    >>
                    >> On Wed, Aug 20, 2014 at 08:51:52AM -0700, bjoseph866@... [extremeprogramming] wrote:
                    >>
                    >>> My company is interested in implementing Agile, ! but we can't
                    >>> seem to figure out how to also incorporate security software
                    >>> development. In essence, we need some best practices on how to
                    >>> incorporate secure software development procedures into Agile.
                    >>
                    >> Some handwavy, context-free thoughts:
                    >>
                    >> A design is secure iff it has accounted for all important functional
                    >> and "non-functional" (hate that term) "requirements" (that one too)
                    >> -- of which you can never be 100% sure.
                    >>
                    >> A security hole is a bug, avoidable in the same ways bugs are
                    >> avoidable -- and equally incompletely avoidable.

                    > Yes, many can be represented as User Stories.

                    > Other aspects can be treated the same way as performance and usability
                    > testing, e.g., test early and often. Watch the trends over time.

                    > - George

                    >>
                    >> When mistakes of any kind (design, implementation, testing, etc.)
                    >> are likely to have security implications, it's even more important
                    >> to arrange for the work process to highlight mistakes ASAP.
                    >>
                    >> If you're relying on the team to make decisions which are likely
                    >> to have security implications, you may want to o! ffer training in
                    >> the kind of practical knowledge and critical thinking required to
                    >> make the decisions well.
                    >>
                    >> If your company can be sunk by one sufficiently bad security decision,
                    >> you may want to involve security experts early and often in your
                    >> development process. You may already be doing so!
                    >>
                    >> More context would help, if you can offer it. Which aspects of
                    >> security is your company most concerned with? What practices and
                    >> procedures have you been employing to address those concerns? How
                    >> effective have they been? What now motivates the interest in Agile?
                    >>
                    >> - Amitai




                    --
                    Best regards,
                    Daswartz mailto:daswartz@...
                  Your message has been successfully submitted and would be delivered to recipients shortly.