2017 Retrospective: The Overdue Post

0 Months left of 2017 - A Retrospective

Dearest, Reader:

It has been a very long and tenuous 9 months since my last post. As much as I have wanted to be consistent with blogging, I have to admit to being a tad lazy. Full Disclosure: my current assignment has been the sole focus of my time. When I'm not testing something, I'm scripting something, or reading about something in InfoSec, or working out and laying low.

Fact is, there's not a whole that that has gone on with regards to Security stuff. My previous post, while informative, is incomplete. Coincidentally, in the last 4 months, I have a renewed vigor for my subject du jour - Pen Testing - and have all but inhaled 2 books relevant to Cybersecurity and currently on one dedicated to Pen Testing. 

Below is a retrospective on what has gone on since my last post, and where I need to do better.

What went right

• Finally got serious about taking my Cybersecurity education to the next level, by way of books
• Being informed in day-to-day events
• Joining the company "Security" Guild
• Networking with others
• Contributing to a VIP client as a QA Automation Engineer

What could have been better

• Actually committing to getting the certifications I need (looking at you Sec+)
• More programming practice (Python, for starters)
• More time allocated to attending Meet-Ups

What were the obstacles

• Time .. truly never enough

Security Testing | Security 4 No0bs - Requirements: The Gathering

Performing a Security analysis for requirements in a story  Web Application Security Testing (pt.2)

Hey all,

In my previous post - Getting started using a WBS - I posted a draft of a WBS that is usable for the project you are assigned to, from a testing perspective. It is by no means a finished product and can be customized as needed. Below I'm going to discuss performing a security analysis for requirements in a story.

1.0 - Requirements Best Practices

Source: http://agilemodeling.com/essays/agileRequirementsBestPractices.htm

• Stakeholders actively participate
• Adopt inclusive models
• Take breadth-first approach
• Model storm details just in time (JIT)
• Treat requirements like a prioritized stack
• Prefer executable requirements over static documentation
• Implement requirements
• Create platform-agnostic requirements
• Create smaller, digestible requirements
• Question traceability
• Explain requirements gathering techniques
• Adopt stakeholder terminology (speak 1 language)
• Keep it fun
• Get Management support
• Turn stakeholders into developers

2.0 - Use Case (sample)

The context for this feature is login functionality for an e-commerce website, where visitors (new Customers) can opt to create accounts so as to facilitate order tracking, adding items to a wishlist, or simply expediting the checkout process. Visitors can register at any time simply navigating the the registration form from the link in the navigation header, or during checkout after adding items to their cart.

ID	ELEMENT	DESCRIPTION	PRIOR RESEARCH
1	User logs in	Registered members of the site can access their profile, dashboard, etc.	Single-sign on necessary for returning customers
Goal	Customers will freely interact with E-Comm agents	Customer Account Management	Client Services Analysis, 2016
Actors	E-Comm Reps, Registered Users	Agents can resolve customer issues; Customers can track their orders	Client Services Analysis, 2016
Pre-Condition	Customer record in DB	User is to have successfully registered in the system	CMS Integration
Post-condition	Profile page; login credentials	Successful subscription will create a profile with USN and avatar	CMS Integration
Trigger	Link in header / cart page	Guest users can opt to register from nav header or during checkout	N/A
Exceptions	Form validation rules	Required field and standard validation rules enforced	CMS Integration

3.0 - Security Analysis

Now that we've identified a feature in test, let's consider the security implications
source: OWASP TOP 10 for 2013

TEST CASE	ELEMENT	DESCRIPTION	SECURITY ANALYSIS
Login authentication	User logs in	Registered members of the site can access their profile, dashboard, etc.	Single sign-on necessary for returning customers; authentication protocols are enforced
Required Fields	Validation rules	Error messages shown on-submit	Messages should not convey the nature of what is wrong, or hint at what should be expected
Boundary Test	Max field lengths	Correspond to data structure in the DB	Should only allow for what is expected in the DB, no more
Character Test	Alpha-numeric data types	Text input validation for expected entry (ex: phone number = numeric keypad)	Non-numeric (ASCII) characters are to be inadmissible on-submit of form
SQL Injection	Commands in text fields	Error handling for script calls	SQL or any other such query language is to be inadmissible on-submit of form
Broken Authentication	Testing password, keys, session tokens, etc	Login authentication is to be handled securely by the server	Verify login authentication can't be compromised; session can't be hijacked; cookies can't be manipulated, and so on
Cross-site scripting	Authentication: session hijacking by way of XSS script	Data transmitted is validated or escaped	Test that XSS is not possible; data is transmitted properly
Insecure Direct Object Reference	Test for Exposure to a file, directory or key	Authentication is valid	User should not see references to file, directory, or the like exposed in the url post-authentication
Sensitive Data Exposure	Testing for exposure to sensitive data post-authentication	Authentication is secured	Sensitive data is adequately protected (stored, encrypted)
Cross-site Request Forgery	Login Redirect	On-submit, user is redirected to the expected destination	CSRF attack forces a logged-on victim’s browser to send a forged HTTP request, including the victim’s session cookie and any other automatically included authentication information, to a vulnerable web application.
Unvalidated Redirects	Login Redirect	System redirect for authenticated user operates as expected	Web applications frequently redirect and forward users to other pages and websites. This should not be the case at log in

4.0 - Requirements

Having scoped the feature, and mapped out some security scenarios, we've fleshed out some potential requirements:

• Login form fields are required
• Login form allows for only alpha-numeric data; where expected special characters are permitted
• Login username is to allow a finite number of text (or check for e-mail input)
• Login password field allows a finite number of characters, of a particular format
• Login form field password text field is to be masked
• Login error messages must be in the right font-style and color
• Login error messages must not communicate what the expected input should be
• Login authentication must redirect user the proper destination - cannot be hijacked
• Login session is managed server-side
• Login url must not past authentication parameters
• Login authentication cannot be manipulated in any way, giving non-auth'd users admin privileges

As you can see, the list can get pretty lengthy. And this is just the beginning!

Security Testing | Security 4 No0bs - Getting started by using a WBS

Applying Project Management fundamentals to Quality Assurance, as it relates to  Web Application Security Testing (pt.1)

Hey all,

This year, my focus is to ramp up my Info Sec. / Web App Security learning and stumbled upon this gem from last year. Figured I could re-purpose it for Security Testing. The scope of this "part 1" is to take the approach of someone assigned to a project and applying old-school practices to get started.

Some of this may work, some of it may not. But the foundation is laid out and it goes something like this:
 

1.0 - Objective

   1.1 - Define testing agenda and purpose of document as it relates to Security
           1.1.1 - Get Project Summary
           1.1.2 - Get S.O.W

2.0 - Testing Scope

   2.1 - Establish what is to be tested
          2.1.1 - Get Testing Requirements from PO / Project Lead / Devs
          2.1.2 - Get Testing Bounds (what won't be tested / out of scope)

   2.2 - Determine level of effort for test tasks
           2.2.1 - Test Types and Duration
           2.2.2 - Test Task Dependencies & Schedule (when to start a new cycle)

3.0 - Personnel

   3.1 - Who are the Client and Stakeholders involved
           3.1.1 - Get names from PO / Project Lead / Devs

   3.2 - Who are the other members on the team (PO / Devs / BA / QA / etc.)
           3.2.1 - Have Kick-off Meeting
           3.2.2 - Get Names, Roles & Responsibilities

4.0 - Security Software & Test Strategy

    4.1 - What Software will be used
            4.1 - Meet w. PM / Devs / QA
            4.2- Discuss best applications / programs to use
            4.3- Discuss testing strategy (best approach) as it relates to OWASP Top-10

5.0 - Risk

    5.1 - Establish risk matrix from features-in-test
            5.1.1 - Meet with PM / BA / Devs
            5.1.2 - Get Risk Analysis from BRD

6.0 - Entrance / Exit Criteria

     6.1 - Determine when testing is to begin
            6.1.1 - Meet with PM / Devs / QA Team
            6.1.2 - Get Release schedules / Test Cycle schedules

7.0 - Completion Criteria

     7.1 - Determine when testing is complete
            7.1.1 - Establish sweep-completion ETA

8.0 - Glossary

      8.1 - Write up all terms, acronyms, and defined language in use
             8.1.1 - Draft list of terms and definitions (including CTAs, navigation end-points)

9.0 - Approval

      9.1 - Sign-off by all parties involved

01.01.2017 Growth! and the changes I want

Act of contrition, take 1

forgive me blogger for I have sinned. It has been too long since my last post. Here's what went down:

2016 can best be described "episodic" - since it started bad, ended great, and marked along they way by lessons learned and awakenings.

Q1 - Winter of discontent

Let me start of by saying that vanity got the better of me in 2016. I let myself get caught up in the fight to make things happen and get sh@#$% done; enamored with the need to feel validated by having a title proper pay. I took a job that gave me just that, proper title and decent pay with the opportunity to make things happen and grow a team with the knowledge and skills I had acquired so far. A win, right!

No. Not even in the slightest.

You see, I took a job that had the promise of everything I was looking for. However, this became a "be careful what you wish for" moment. In my vanity - loving the title of "Manager" - I failed to read the fine print. I failed to see the bigger picture. I failed to do the very job I was hired to do. How, you ask?

Well, the environment I worked in was quaint. The people I worked with were friendly albeit somewhat distant. But the product I worked on bored me. Testing the same thing over and over became routine and monotonous. I fell out of love with this thing I was supposed to be responsible for. I stopped caring about the very thing QA Managers are supposed to care about. (Confession: I was a bad tester, not bad at testing, but unmotivated to be better)

I embraced the quality thereof, but I wasn't sold on its appeal. Worse, I didn't care anymore. As time went on, I began to feel more isolated and alone. I was frustrated and lonely, and craved change. I wanted camaraderie but found none. I wanted to learn new things, but was getting tasked with menial assignments. And this eventually reared its ugly head in my work performance, which greatly suffered. The consequence: termination. The feeling: elation!

Q2 - The turn-around

January and February of 2016 and I found myself unemployed, but somehow relieved. The weight of a burdensome job was lifted. Luckily I saved just enough to cover several months of expenses, with my unemployment pittance covering the rest. Dear reader, being without work feels great at the beginning - the honeymoon - but over time, the reality sinks in, the bills pile up, and desperation sets in. It can be a total mind-f**k if you let it.

Being without work can also be a great time for soul-searching and opportunity. I took the approach of using the time to learn new skills and gain new experiences. I practiced some much needed automation programming, I networked at meet-ups, and I kept an upbeat attitude. I used this time to make things happen and get sh**t done, per my new year's resolution mantra. And that I did.

As it would happen, March was a total bust. In my vigor to make things happen, I came down with a slight case of pneumonia which side-lined me for the entire month. No going out, no computer work, no blogging (sorry!), and no working out. It was a 30-day moratorium on life. Then along came April (the month, not a girl!)

Q3 - The re-awakening

Easter comes in at the end of March, and usually symbolizes rebirth and renewal. By April, this was my rebirth. I came out of my malady with a renewed confidence and strength. I resumed my daily activities of working out, job hunting, soul-searching, and getting back on track. Should have blogged, but got caught up with other things of more importance(again, sorry!).

April began with a tremendous job opportunity (current place of employment). Where I'm currently at is a start-up, like all my other places of employment, and presented itself as a small company with a project for a prestigious client. To say I was blessed to be hired and tasked with this project is an understatement. I work for an awesome boss, surrounded by amazing people, and work on a project I absolutely own. I'm at a place that really cares for your overall personal and professional growth. They invest time and energy into making sure you 'bloom where you are planted'. Do I need a title? Nah! Is the pay adequate? Better than adequate, as I'm making more than at my former employment, with much much better perks.

Fun fact: I had interviewed at the parent company some years back and turned it down for economic reasons (the position was contract). How fortunes have changed in my favor.

Q4 - Spiritual rebirth, renewed vigor

So here I am, dear reader, having a tremendous career rebirth. Some time ago I considered quitting QA Testing altogether and was contemplating web design. But I am at a job I truly embrace. I enjoy going to work. I welcome the opportunities it presents. And I have something to look forward to now in 2017, for you see, I am now part of a committee that is exploring ways to incorporate WEB APPLICATION SECURITY TESTING into its core competencies (shivers with excitement!)

A year ago, I was on the outs. 365 days and some odd hours later, I have optimism like never before. And its only the beginning - day 1.

2017 - GROWTH! and the changes I want

2017 is looking to be a promising year. I endeavor to keep them coming. For you see, the mantra for this year is growth. Spiritual, Financial, Physical, and Professional. In the months to come, I plan to build on my skills and level-up. That means hitting the Security track hard (not just talking the talk, but finally taking action).

2017 -- GROWTH!!!