Affirmation | What Door Are You Walking Through?

The above-heading is derived from a recent lecture given by Minister Joel Osteen on his weekly program titled "Joel Osteen Ministries"

Dearest Friend,
I have a confession to make: At my most recent engagement, I held myself back from personal and professional growth. The end result cost me a tremendous opportunity, a great salary, and employment. As I reflect on what went well, and what went wrong, I can honestly say there was a lot that could have been done better on my part.

What went well:

For the most part, I can honestly say I found myself working in capacity I love best. I was happy working with a small team, but mostly I was in my comfort zone doing the thing I enjoy - coding. The end result was building out, not one, but two frameworks for automation. One of which is still in use as we speak.

I was also tasked with helping on distinct projects, performing manual testing, and some accessibility. Overtime, I found myself splitting my workday between coding, testing, and handling day to day tasks assigned to me by management.

I had the privilege of working with fellow testers and engineers, providing feedback, and offering ways to improve their work as well. What followed was the best six months of my work. I genuinely loved being on the team helping to find issues early, streamlining our efforts, and what-not. Sadly, it wasn't all good!

What went wrong:

I won't go into a rant about how much disdain I have for the current "cancel culture" that is rampant in the professional world. Nor will I express my displeasure at how workers get treated like disposable items. I will dedicate this time to illustrate where I failed. This is what I'm owning up to as the mistakes made, that I might need to correct immediately.

• Was not mindful

  So there was a lot of good that came out of my first 30 days. But as I went along, I never felt like I gelled quite right. The work detail kept changing a bit, and while I was still doing my coding thing, I recognize I failed to pay attention to the bigger picture. Too often I kept hearing how I had to "zoom in" and "zoom out"; focus on the details, but see the bigger picture. Something I definitely need work on.

  There were times I did catch myself doing some dumb shit. I will own that. Times where I felt like I was there and not there; present at work, but aloof of the project I was on. Some of it had to do the learning curve of being new, but other times it was just my insecurity.

• I still lacked confidence

  It had been several months, and a 10-day vacation, since my former employment and subsequent layoff. While I thought I was over it, I was still plagued with insecurities. I did my best, but too often I felt like I was a beaten dog. Doing well, working hard, and being the best possible contributor to the workplace meant nothing if at the end of the day, I would get laid off.

  It was on one such occasion, when my initial project had reached its end, and my allocated hours shifted, that I saw on my sheet a vast set of blank spots. My elation became dread; The joy of coming to work turned into a countdown of the inevitable. I was assured that it was nothing .. no one got around to it yet .. I could just ignore it. My mind was made up, and my gut was barking loudly: something wasn't quite right. Enter the doubts, the paranoia, and ...

• Imposter syndrome

  In all my professional experience, the good and the bad, I always prided myself in the work I did. I was never one to brag about my accomplishments, nor was I one to gloat on work done. I was the quiet co-worker that spoke through my work. But several new assignments and tasks, along with a sense of foreboding, had me feeling like I was a fraud, a fake, a bad hire. I was brought to this company on a referral and my performance had all but exhausted that good will.

  It as on such an assignment, tasked with working on a coding task with technologies I had never been exposed to, that I came to understand the true limits of my reach. The win was I was able to complete the task - albeit with the help of others - later than I wanted (due to shifting priorities), but never before had I experienced panic attacks and doubts in my ability. If I wasn't paranoid before about my job security, I was now. But what contributed to this was a growing sense of ostracism; like more often than not I was out of the loop. Like I ...

• Did not fit in

  In my former employ, the kinship and camaraderie formed with the team I was a part of had a profound effect. From the first week that I started and the years thereafter, it felt right. Not so much in this new place. Too many times the interactions were fleeting, barely noticeable, with hardly any connection made. Six months in and I still felt like a stranger in a strange land. Despite all my efforts, I just never felt settled in. This feeling coupled with my insecurity contributed to my decline in performance. July was my worst month.

  Then along came 9/11. We started that morning on a low. Several of the people I had bonded with were laid off. This sent me into weird funk. I recognize that now that I was in a downward spiral of depression and loss. One such co-worker I connected with was disposed of like nothing .. and she was a parent with responsibilities. It wasn't fair. I didn't handle it well. I found myself rebelling in a passive way. The quality of my work took a nose-dive and I exhibited a lack of enthusiasm. I recognize I ...

• Did not work to my fullest potential

  Three months into my job and I felt like things were ok. But as old projects ended and new ones started, there was a lot of downtime and opportunities to grow into my role. But I was hired as an Engineer setting up the automation solutions to be put to use on future projects. I did not want to take the reins of a project as a lead. I also did not want to assume any more responsibilities than I cared for. Those days for me were over.

  But management had different ideas. While I fully understood my role, I never fully knew what the expectations were for my position. The few ideas that were communicated to me were ones I embraced. But I purposefully held back from what I was expected to do because my past had taught me that hard work doesn't matter if the outcome is the same. Which brings me to the purpose of this post.

What Door Are You Walking Through?

Knowing where I failed, I know now that I can do better. I can BE BETTER. And it starts with what motivates me; when my heart is in it, I'm stellar. But it's mostly about embracing the opportunity to do something challenging. Take the risk. Grow into my purpose.

Its time to let go of old attitudes. One of the things that has plagued me from that momentous first termination is the chip on my shoulder. I still have a disdain for management, and I care very little for workplace politics. But as my resume has shown, when my heart is not in it, when I just don't care or am not happy, I don't put forth the kind of energy that keeps me employed very long.

In this coming decade, I plan to put these into effect:

• Exhibit excellent problem solving and analytical skills
• Give off positive energy and a friendly collaborative attitude
• Will possess attention to detail and quality in my work
• Have the ability to trade-off getting tasks done with stepping back to see the big picture
• Be mindful of where I am at and bloom where I am planted

I need to step up and take responsibility for what I do, not just for myself but for my family. The time has come to walk through that door!

Affirmation | Focus On Your Goals

We briefly interrupt this blog post to bring you the following pep talk ...

Following on the heels of my recent post where I talk about what I've learned in the past 10 years of being in this field, I want to take a moment to reflect on some of the points that have been consistent along my journey.

I heard it mentioned by a great tv minister that more often than not we go through "seasons" of discomfort as a means of sharpening our edges; that we are tested as a way of building character and getting stronger. Too often I have found myself in situations where I've been tasked with doing something I was unfamiliar with or that was outside my skillset. Most of the time, this has worked out. Sometimes though, this has failed spectacularly.

In another broadcast, there was a mention about our path in life and where we are supposed to be. My take-away at the conclusion of this broadcast was that I am where I am at because it was ordained by a higher power. Having been through a series of layoffs, terminations, forced resignations, and what-not was the will of the divine providence guiding me from the place where I should not be to the place where I belong. I want to believe this is true as it explains my career path thus far. But I also have to recognize my own faults in contributing to the many "changes in employment states."

No matter what new opportunity presents itself, I often apply some choice words I want to impart with you, my reader:

Slow Down!

• Take a minute to be grateful for where you are, even when it feels like you would rather be somewhere else
• When assigned a task, take time to re-read what is being asked and "grok" what is being asked before you dive in

Focus

• Quiet any linger pangs of doubt or insecurity ... you got this!!
• Avoid Unnecessary Distractions
• Stay on task and never lose sight of what is most important

Stay Aware of your skills

.. be mindful of what you do and don't know

• Recognize you don't know everything and you have to know your limits
• Do not put up a front like you know what you are talking bout ... if you don't know, its ok

Plan

• Set proper goals and stick to them .. don't loaf
• Get yourself organize with a task list
• Remember to set up a plan for any endeavor (Development, Testing, Working out, etc.)

Do

• If you intend to say something, say it with tact
• If you intend to do something, do it with all your heart, or don't do it at all
• Be at your best each and every day
• Bloom where you are planted .. be so good you can't be ignored

Act

• Give 100% in all things, in all ways

Check

• You are never to declare you are done until the thing you have set out to do is consistent and to spec, or you just cause headaches all around

Thank You! We now resume with your regularly scheduled blog post

Work on thinking through problems (not letting project pressures disrupt that process)

Affirmation | Don't just go through it .. GROW through it

10 years in QA: A brief retrospective

This Thanksgiving week - November 2019 - I will be celebrating 10 years in this field. I came to this field, on this same holiday, back in 2009 with zero experience in Quality Assurance (QA), testing, or any formal training. At the time, I was studying information systems security (a passion I still wish to pursue).

I interviewed for the position at a start-up agency with nothing more than some first-hand knowledge of compliance like Sarbanes - Oxley Act, HIPPA, and a few others, as well as a "can-do" attitude. They took a chance on me and I've been grateful ever since.

It has been a turbulent decade, filled with many highs and a few too many lows. A career that has included a steady climb to the top of the mountain - as a Manager - and currently serving as automation engineer. I will recap some of those highs and lows as befitting the tradition retros I have come to participate in while employed at many of these companies.

LIKED

• The current engineering path I am on is heaven! Automation is the greatest skill I have ever learned

• I got the opportunity to work with some amazing people, some of whom are still friends

• I got the chance to work on a wide array of applications for web and mobile

• In Agile, Test cases are an antiquated artifact that is no longer utilized

• Workplace lunch & learns have been a blessing, and I love to participate when the chance arises

---

LOATHED

• Workplace politicians can make this job unbearable

• Too many managers place a high value in Key Performance Indicators (KPI) as a way of measuring progress

• Workplace optics matters, but never for the right reasons

• I've come to the realization I really really hate micro-management

• Having to perform full regression tests on complex apps with no context on what was changed, in a short window of time

• Having to work long nights, weekends, and some holidays with no appreciation

• Getting laid off too many times for financial reasons

• Getting fired for trivial (or political) reasons

• Performance Improvement Plans (PIP) .. the instrument of purest deceit and guaranteed dismissal from employment (happened twice)

---

LONGED

• More opportunities to practice security testing

• Workplace mentor, especially when I first started. Its been rough having to learn on my own

• Career stability

• Proper certifications in Security (need to get on this)

---

LEARNED

• BOSS ISN'T ALWAYS RIGHT, BUT THE BOSS IS STILL THE BOSS

• Never accept anything you are not comfortable doing

• Bringing QA in early on a project is invaluable

• I have the potential for leadership, but I've come to learn its not a path I wish to take

• I got to work with earliest versions of iPhone, Android, Blackberry, and Windows devices

• I am at my best when I am given creative freedom and autonomy in tasks to be done

• How to work with offshore teams

• How to work with QA Outsourcing Companies like Applause

• Have learned automation skills working with different frameworks

• Automating iOS and Android apps (barely, but a lot has changed since I tried this)

• Work with DevOps, Jenkins, and collaborating on best ways to approach CI/CD

• Have finally learned how to use Postman effectively

• You have to stay on top of your skills or become obsolete

• You are an asset until you are not, then you become expendable

• I've learned to work in both Waterfall and Agile methodologies

• In one engagement, I learned how to run a team of like-minded people

• Have worked testing front-end, back-end, CMS of all kinds, some performance testing

• Have learned how to work with security tools (the learning continues)

• Learned the power of HR, positives and negatives

• I have learned there's no such thing as workplace loyalty

Security Testing | Security 4 No0bs - Saying 'Yay' to BYOA

How could BYOA (bring your own application) play a part in security?

Source - Ministry of Testing - 30 Days of Security Testing Challenge (2017)

Dear reader, I'd like to take a few minutes to present my take on this whole idea of personal apps on personal devices whiles on company time. Seems like the issue of BYOA is ever-increasing as more and more business adopt cloud-based solutions for things like data storage, design, collaboration, and the like. Using the metaphor of a box as security, every user with a personal device using their own apps is poking holes in the box. It's not hyperbole to regard each app (non-Company Approved)as a potential attack proxy.

With that said, the following is a list of things off the top of my head that I see as issues resulting from BYOA. Its a simple list and I'm sure more can be added as IoT evolves:

What is BYOA?

As it is defined in most places, BYOA (Bring your own application) is the practice of using third-party applications. This can be anything cloud-based, external-facing, or otherwise remotely accessible.

The problem inherent in this practice stems from individuals, with personal devices, introducing apps that can utilize the same resources as other applications in the system, in essence making them "friendly".

What harm can it do?

1. Cloud-storage Apps

Locally, users may be able to store and retrieve data from a centralized system. Monitors are put in place to track the flow of data, and roles-based access determines who gets what.

The challenge is how to control this stream of data in the cloud.
Authentication credentials may provide some form of control, but the likelihood of a data breach, social engineering attack, or other means of accessing the server is high.

2. Collaboration Apps

On the surface, collaboration apps appear harmless, but if an application not approved by Network Administrators is used, there is the potential for exposure to attacks not limited to trojan horses or packet sniffing.
Network Admins may have a tough task of regulating what is / is not admissable on the network.

3. Social Network Apps

Another potential attack vector, social network apps present the opportunity of introducing malware into the system by way of interacting with the wifi, blue-tooth connection, and distinct device settings.
All one has to do to introduce such an attack is simply click on a link, post, or image and **BOOM** an attack has begun.

What should I do?

Granted there are more scenarios that illustrate the point I'm trying to make about BYOA, but the solutions to ensuring the chance that a security incident never occurs is to be mindful of the apps in use.

While at work, be to use apps approved for work use only, and be cognizant that any communication using company resources will be monitored. Any suspicious activity will be flagged.

What should I NOT do?

The answer to this is simple:

1. Don't use "your" apps for work

As an employee (end-user), one should strive to avoid using any unapproved applications.

2. Don't use "your" social apps during work hours

Avoid sharing anything, clicking anything, streaming anything, or downloading anything not work related.

3. Don't store anything in the cloud

Storing copies of any company information remotely. This may be construed as a security policy violation with dire consequences.

Conclusion

As a user ...

Keep a close eye on the apps that you ARE using, especially ones approved for work, and keep any non-work related activity for when you are off the clock.

As innocuous as it may be, the idea of BYOA is novel but perilous. The transmission of information - Inbound / Outbound - is a security risk no organization can afford.

Security Testing | Security 4 No0bs - Web vs Mobile Security Testing

Web vs Mobile Security Testing: A No0b's Observation

Dearest Reader, As I am moving along in my journey towards learning more about information security and testing, I've come to understand how the pieces fit.

While my testing experience began with mobile, a lot of the testing principles carried themselves to the web. Browser nuances aside, I've noticed distinct similarities in how applications work, and some obvious differences.

The same can be said with regards to security testing.

How Web & Mobile are the similar

Some of the similarities I've encountered with regards to Mobile versus Web Application Security Testing include:

1. Browser behavior
So the first thing I've come to realize is just how similar web and mobile behave. As it relates to presentation, the UI interactions are identical. A mobile-friendly site can elicit the same response as a native app. This presents the ideal playground for hackers to take action. A user can view a site or install an app from a "trusted" source and unknowingly introduce trojan horses in their system. Its been reported just how rampant the spread of malware is from trusted app stores.
2. SQL / JS Attacks
In my testing experience, I've come across both web and app forms that fail to follow certain design patterns. The first of these patterns being max field length constraints. All-too-easy to enter verbose text and cause a crash or other negative behavior.
Another common situation involves the lack of proper input restrictions. While easier to mitigate on web, more often than not the likelihood of injecting malicious code into a form is evident when the controls to prevent special characters from being entered are not found.
Imagine being able to trigger a "DROP TABLE" command from a form that isn't preventing the system keyboard from entering special characters where none are expected. Not good!
3. Data Manipulation - MITM
While this required a little more effort, the means by which submitted data could be manipulated occurred the same way both on web and mobile devices. Some time ago, I was tasked with testing an app that required user input in order to trigger an SMS operation.
With the help of a proxy tool, I was able to manipulate the payload and transmit gibberish where a legible message was expected. I've successfully done this on web sites as well.
4. Session Hijacking Attacks
Because web and mobile apps rely on cookies for state-transitions and navigation, the means by which sessions can be hijacked are identical. With the help of proxy tools, session tokens can be intercepted and manipulated, wreaking all kinds of havoc.

How Web & Mobile are completely different

In my opinion, not a lot separates web from mobile aside from the obvious differences in resource and hardware. There may be more to this list than I can possibly mention, but I shall endeavor to keep it short and sweet.

1. Native SDKs
So the first thing to mention is the SDKs. In this category, iOS (Apple) has the clear advantage with regards to how it manages its application universe. With the way they handle release management and policies regarding application submission, Apple ensures its operating system remains tamper-proof. But recent exploits have shown nothing is unbreakable.
Security testing apps involves using a lot of proprietary tools and the biggest challenge is overcoming the iOS restrictions.

Android, written in JAVA, presents an implicitly easier way of testing apps from a security stand-point. The biggest challenge however, is the device ecosystem. While testing may prove stout in many of the devices, lower-tiered devices using a legacy-version of the Android OS may prove likely targets as their code-base might be not patched.

2. Tools To Use
In my experience, working with native apps and web sites, the tooling for security testing is diverse. That being said, the one tool I found working the best way was BurpSuite.
Where the differences lie are in how you proxy the device to interact with the framework. On a website, one just sets the IP address to be detected by the proxy tool and VOILA! you are being detected.
With mobile devices, one has to create a Certificate with the proxy credentials. Then the certificate must be installed onto the device. Lastly, the device wifi and proxy suite must reside on the same network.
Another key difference was applying OWASP Top-10 test cases. The test cases for web did not translate 100% to mobile, and vice-versa (ie., there were subtle nuances to account for).
3. Attack Vectors
As stated before, while the device ecosystem is stout for iOS, this is the complete opposite for Android.
There are a plethora of devices, OS versions, and other fractious iterations in the wild, not to mention rooted devices, that testing and securing platforms proves an enormous endeavor.

Conclusion

This list is in its infancy and may evolve over time, but for now .. this is what I got!

• OWASP_Testing_Project
• source.android.com/security/
• iOS_Security_Guide.pdf

30 Days of Automation in Testing | Testing Made Faster

Speeding up automated checks & execution time

The problem(s):

1. Too many functions happening at the same time
A lot of verbose syntax and unnecessary UI waits anticipating lags from the back-end.
2. Too much of the Step > verifyThis() > doThis() > Step_

Another thing that choked the script was adding assertion / verification checks for each step of the test.
What ended up happening was an unnecessary delay in test execution often leading to false-negatives or script failures.

3. Spaghetti code

As newbs to automation, the mistake I've seen is poorly written tests with a superfluous amount of steps and repetitive code to accomplish the simplest of tasks.
I was guilty of this for a while. Until I learned how to abstract my scripts into distinct code-blocks.

The Solution:

So what worked for me was changing how I approached test composition with a strong focus on making it legible so that anyone can look at the test and know what's going on.

Before, a lot of times, a test (written in JS, for example) would look something like this:

driver.setUp(); driver.getUrl(“http://example.com”); driver.findElementById(’//a[@text=“register”]’).clearText(); driver.findElementById(’//input[@id=“textBox”]’).clearText(); driver.findElementById(’//input[@id=“textBox”]’).sendKeys(“verbose code”); driver.findElementById(’//button["@id=“submit”]’).click(); var pageTitle = driver.findElementByTag(’//h1[@class=“pageHeader”]’).getText(); assert pageTitle == “Success Page” driver.tearDown();

As you can see, the test is a bit hard to read and not very descriptive of what is going on. Having applied the Single Responsibility Principle, I rewrote the test to look something like this:

Using Katalon

WebUI.openBrowser( pageUrl );
WebUI.click( registrationLink );
onRegistrationForm.CompleteAndSubmitForm();
onProfilePage.VerifyInfo();

Notice the following:

• pageUrl - I didn't need to explicitly write out the site url, I can declare a variable and reference it


• registrationLink - as stated, I declare my variable elsewhere and call it here


• onRegistrationForm || onProfilePage - these are classes I create in a separate file and import it as part of a function (package).


• SubmitForm () || VerifyInfo () - Each class has a set of methods. A class can have many functions, but there should not be any occurrences of multiple classes on the same file (_hence SRP_). The exception being helpers .. but that's another topic.


• I also reduced unnecessary element checks on the test and have them happening as separate actions in the aforementioned classes. The end result makes it easier to maintain the test by fixing only the function that needs it.

Conclusion:

While the "Solution" example was written in Groovy, I've applied similar concepts when writing tests in JS or Python. I like that the test is readable and that anyone can see what I'm testing in seconds.

It makes it easy to pair the test scenario with the acceptance criteria to ensure the proper workflows are being tested.

It also makes it super-simple for anyone inheriting my project to see what I'm doing and pick-up where I left off. An import thing for teams.

Security Testing | Security 4 No0bs - Personal Wiki on Information Security Stuff

Running into a lot of great articles, stashing them here:

• OWASP Top 10 Cheat Sheet
• DNS Spoofing (Wiki)
• SSL Roadmap (Wiki)