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)

30 Days of Automation in Testing | Tests & Testability

Dear Reader,

Regarding the subject of testability, there are many opinions that yield similar single conclusion: code, as it is written, ought to be testable.

Where the divergence happens is in how the aforementioned code is written. Some take to abstractions, where chunks of code are split off into separate sections.

Others keep the code in-line leading to verbose composition.

Then along comes the Single Responsibility Principle.

What the Single Responsibility Principle (SRP) taught me, a noOb Automation Engineer

Not too long ago, an awesome teammate (Dev) introduced me to SRP and the code concepts behind it.

We were working on a project and our synergy was off-the-charts. I would automate a lot of the test efforts thereby maximizing the turn-around time to fixing bugs and he would help with code reviews and solutions when I hit a wall.

Along the way, he passed along the tidbit of information regarding SRP and it opened my mind to a new way of thinking about how I need to restructure my tests.

Code Quality

One of the first take-aways from learning about SRP and S.O.L.I.D. principles (click link for more details) is that test and the code they're written ought to be neatly composed and clearly structured.

• A class should only have one reason for change.
• A class can have many functions, but not the other way around.
• A module should never consist of multiple classes.

Code Efficiency

Another take-way was modularization of tests.

• Increased Speed - By keeping modules separate, the speed with which tests fire become greatly improved.
• Greater Reliability - modularizing tests increased reliability at deployment and improved as more and more tests were added to the test bed.
• Flexibility - as the project evolved, tests can be updated / removed with minimal to no impact to the rest of the test suite

Code Legibility

• Improving code efficiency parlayed into better code legibility. By abstracting tests into methods and keeping classes separate, I went from a verbose test filled with "spaghetti code", method calls, variables, and the like, to something that reads like:
• openBrowser(url)
• onTheHomePage.clickLogin()
• onTheLoginPage.enterCredentials()
• onTheLoginPage.assertLoginIsSuccessful(message)
• closeBrowser()

Code Maintenance

As more and more tests were added, and the test suite ballooned to well over 40 tests, the need to maintain this volume of tests, and test resources that went along with it, began increase proportionately. With the application SRP, test maintenance became less daunting.

• Test Data - Data that feed the variables for a test step now came from an external data source instead of being hard-coded.
• Test Scripts - with the ease of legibility, tests could now be shared and discussed with non-technical members of the team. Feedback yielded additional action in record time.
• Test Reporting - with the improved structure, tests could now better reflect what was being tested making reports and error handling much more succinct.

Conclusion (tl;dr)

Single-Responsibility Principle & S.O.L.I.D proved instrumental in how best to structure my tests scripts into a clean, concise, legible test harness that proved to be efficient and effective at articulating workflows, providing timely feedback to the Developers, and finding bugs in a reliable manner.

Resources:

• SRP Wiki - https://en.wikipedia.org/wiki/Single_responsibility_principle
• https://code.tutsplus.com/tutorials/solid-part-1-the-single-responsibility-principle--net-36074
• https://codeburst.io/understanding-solid-principles-single-responsibility-b7c7ec0bf80

30 Days of Automation in Testing | Type of Automation Testing Supported

Type of Automation Testing Supported

Original Post: what-types-of-testing-can-automation-support-you-with

• UI / Front-End

  • Normal Flow - automation can streamline the end-to-end testing of typical workflows and critical paths
  
  
  • Exception Handling & Validation - with a data source, testing is more efficient when the process for generating error states and system failures is automated
  
  
  • Boundary Testing - the process of filling forms with copious data over time is best completed via an automated script that can dynamically enter the data consistently
  
  

...

• API / Back-End

  - Basic Assertions that data is present / POST - data matches input / GET - requests are not null



• Integration

  - systematic testing of all features as they've been assembled with regards to the rest of the other features in the DOM

...

• Security

  - Vulnerability Assessments, Proxy/MITM Attacks, Brute Force Attacks, DDOS

30 Days of Automation in Testing | What skills a team needs to succeed with automation in testing

What skills a team needs to succeed with automation in testing

Original Post: share-what-skills-a-team-needs-to-succeed-with-automation-in-testing

Dear reader,

With regards to success in automation, teams succeed when each of the players knows their role. As it pertains to QA Engineers, there are definite skills that help, as listed below:

Technical Skills

• Fundamental Knowledge in the SDLC - knowing what it takes to plan, develop and deploy. Also knowing the concepts of TDD vs BDD.
• Requirements Gathering - while not necessarily technical, there are some technical aspects in terms of understanding the best script language to choose and why, how to work with the CI, and so on.
• Programming Language - as has been stated, familiarity of a computer language is key. It also helps to work in the language of the developers so as to become part of the build process.
• Knowing the basic differences between Unit and Integration tests, as well as Front-End vs Back-End testing.
• Page Object Modeling
• Object-Oriented Programming
• Continuous Integration - understanding how to deploy to a CI and maintain the scripts as the project grows.
• GIT - I can't stress this enough that all QA Engineers need to have even the most basic of knowledge of the GIT workflow.

I can honestly tell you a lot of team success also relies on the inter-personal dynamics and non-technical aspects; the intangibles that make or break team unity:

Non-Technical Skills

• Be Adaptable - as a QA Engineer, it is paramount that you are adaptable and willing to work outside of your comfort zone. Sure you know Python, but does that help the Devs if everyone is working in JS? Also, there must be the willingness to learn a new framework if the one you have experience with doesn't work for your current project.
• Be A Leader / Mentor - as a subject-matter expert, you must be willing to flex your "coach" muscles and pass on what you have learned. Its good that the junior members of the team can write page objects, but its on you to be able to coach them on why IDs are better than XPATH or how to better compose a test case.
  A good leader motivates the rest of the team and raise any flags that impede success.
  A good leader can also advocate for automation if it doesn't exist, and can evangelize a particular framework or script language if the current one is not working. It takes the right manner of communication and tenacity to express your beliefs and what you honestly feel will work for the team. Have proof of concept if necessary.
• Be Creative - as someone who was tasked to work with proprietary test framework last year, an application that required knowing JASMINE (_something I've never been exposed to_) it took a minute to gain a foothold. When I did, I found myself working with the team Automation Engineer who built the framework to create the kind of tests that were versatile and resilient to change. The end result was a fluid test harness that was tremendously advantageous as the project grew in size.
  The lesson learned: creativity goes a long way when it comes to writing the kind of tests you want in a way to make it easier to maintain.
  Example: if you know you have many tests relying on test data, find a way to map the test to a data-source and structure your test in a way that uses variables rather than hardcoded data. Simple, right?! But now imagine this is on a platform you've never seen before. What are you to do?
• Be Positive - the hardest part of automation is the loop of **write test -> run -> fix** especially as project requirements change. It can be frustrating when the environment goes down causing you setbacks, or when page structure is updated and tests that once were passing are now failing.
  Overall, there are 1,000 different things that can impede your progress. But what you cannot do is get negative about it. The challenge is to persevere when things are tough. This is key in a team situation when your progress is contingent on the success of others.
• Be Passionate - As the saying goes, _a chain is only as strong as its weakest link_; everyone on the project has their part to play. You may be called upon to test manually or give a demo on work performed. Whatever the case, be committed to the craft. Give 100% in everything you do.

30 Days of Automation in Testing | Favorite Automation Solutions

Day 13: Best Automation Solutions

Original post: share-your-favourite-automation-tool-and-why

In my experience, my top **3** the following have worked:

CodeceptJS - for those with a javascript background, codeceptJS is a great UI framework with a syntax that is easy to learn. The frame work can be adapted for customized usage or with other libraries.

Katalon - written in Groovy, this framework is hands-down my favorite in terms of reliability and ease-of-use. I came upon it while researching an automation test solution for my company. Having previous experience with similar proprietary testing solutions written in Jasmine, adapting what I learned was effortless.

• Can it test cross-browser?

  YES

• Can it test on mobile devices?

  YES

• Can it test web services (API)?

  YES

• Does it take screenshots and post reports?

  YES

  &

  YES

• Can it run in a CI?

  YES

• Can it work with GitHub ?

  YES

• Can others collaborate to a project?

  YES

The tutorials are intuitive and the fact that you can even employ javascript within makes this a robust platform.

Python

-- I have not yet found an out-of-the box solution for anything written in Python, but I've written custom tests that have proven super-reliable and quick to run.
My learnings for Python are in their infancy, but I have found using a lot of success with http://selenium-python.readthedocs.io/index.html

For API tests, Postman and FrisbyJS have been a godsend.

30 Days of Automation in Testing | Advice For People Getting Started

Best Possible Advice

..from someone self-taught

Dear Reader, If someone were to ask me how did I get started in test automation, my answer would end up being some derivative of, "I just installed Selenium and poked around for a bit." Then as I got more curious, I started asking more questions.

My top 5 list of things I would recommend are:

• Always Be Curious

Coding skills are great and all, but never accept that you know everything. Keep learning new things and asking the question, "how do I do ?"
Also its worth learning how the pieces fit. Not just how the feature works, but how the feature integrates with the other sections, or how the page interacts with the database.

• Always Be Learning

Never accept that you are good at just 1 test framework or language. Be open to try a new language or new way of doing things.

• Do As Devs Do

And by that I mean learn how to be a part of code reviews and the integration process.
If you code in their language, you may be able to learn more and ask the kind of questions / test in a way that adds more value to your role on the team.

• Advocate for automation

If your QA team or company does not have an automation process, or your project could benefit from this, be a strong advocate for implementing this type of a solution. Work with your team and propose a viable solution that can benefit the project development lifecycle.

• Pass On What You Have Learned

Once you get to a strong level of confidence in your skillset, pass on what you have learned! Be prepared to give a presentation on your findings, or be ready to mentor others who may be interested in learning.

30 Days of Automation Testing

Now for something completely different ...

30 days of automation in testing challenge

challenge .. accepted!

Dear Reader,

I will be dedicating the next few posts to the 30 Day Automation Challenge offered by Ministry of Testing. I remain fully vested in all things Information Security and I have things to share regarding my progress with learning Python, finally getting through Kali Linux (Beginner), and finishing the first part of the Lynda.com courses on Penetration Testing. So much to get to.

teaser: What I thought of Kali Linux and the associated learnings

But then I'm also into automation and will be posting all my progress in the next few weeks. Promise!!

For more information on the 30 Days of Automation Challenge, click here:
https://ministryoftesting.com/dojo/lessons/30-days-of-automation-in-testing

Up next, the first of the challenges:
* What types of testing can automation support you with? Share an example.

(credit: https://club.ministryoftesting.com/t/30-days-of-automation-in-testing-day-1-definitions/16221/16)

Security Testing | Security 4 No0bs - Whats the RISK?

Risk Assessment: Web Application Security Testing (pt.3)

Hey all,

In my previous post - Requirements - The Gathering - I briefly discussed requirements best-practices and what it takes to get to analyzing a story and drafting best possible test scenarios. From these scenarios, we get a list of potential requirements for the feature - in this case, login. With that, let's discuss risk assessment.

Below is the list of requirements derived from the previous post

• 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

Now, let's look into: Threat Modeling

source: https://www.owasp.org/index.php/Threat_Risk_Modeling Threat modeling consists of 5 basic steps:

1. Identify Security Objectives

2. Survey the Application

3. Decompose it

4. Identify Threats

5. Identify Vulnerabilities

Security Testing | Security 4 No0bs - Posture Assessment For An Application

Continuing our "Security 4 No0bs" series, I want to discuss what exactly is this thing called a "Posture Assessment" and how it applies to information security

 

Source: Secure Force - Security Posture Assessment

What is a Security Posture Assessment?

In a way, the Security Posture Assessment (SPA) is kind of like a S.M.A.R.T goal for an organization, as it relates to cyber readiness. The text definition is, "an organization needs to be able to assess their cyber-readiness holistically."

How does it work?

Applying the S.M.A.R.T principle, we can say that an organization can determine their cyber-readiness by setting forth an assessment based on the following (simplified) list:

1. Specific

An assessment of the current state of the security posture is conducted by way of an audit, be it internally or externally; an assessment of the security posture at both a micro and macro level. Based on the results, potential solutions are presented.

2. Measurable

The impact of what was discovered during the audit needs to have some weight (value) associated with it. This can be in the form of a Severity "1-to-5" or "Critical > High > Medium > Low" scale. Whatever is used, the point is to assign a value to the issue so as to take the appropriate response.

3. Achievable

Once solutions are provided, the tactical feasibility is taken in to account. These solutions can become part of an overall program, be it Disaster Planning & Response (DRP) or Continuity of Operations Planning Program (COOP). The solutions outlined must be able to be accomplished within a reasonable time frame and within a budget of some kind.

4. Relevant

The combined results (a Vulnerability Scan performed + Audit + Security Assessment) should be modeled against the security architecture in place. The end result is a concise list of actionable items carrying a point-value and criticality metric relevant to the application or business function.

5. Time-Based

As stated before, the SPA ought to have some degree of efficiency as it pertains to INPUT -> PROCESS -> OUTPUT.

• INPUT

  Initiation of a SPA ought to begin based on a request (trigger) or response to perceived issue, in a timely manner

• PROCESS

  The scope of the SPA can be achieved when all the necessary information is acquired on time. Same goes for completion of any vulnerability scans, security audits, and other such assessments.

• OUTPUT

  The overall conclusion of the SPA has an expressed date and time, but by no means is to be regarded as finished. One can define "Done" as: submitted comprehensive list of recommendations via report, waiting on response and follow-through.

Why bother with this?

In this day-and-age, cyber security is paramount to business continuity as well as web and mobile application security. A SPA, taken as part of a larger comprehensive cyber readiness initiative, adds an immense value to the overall constitution of an organization. It is imperative to the integrity and reputation of a company of any size to get "cyber ready" post haste.

Security Testing | Security 4 No0bs - 5 Steps to a quick Security Audit

The process and procedures around Security Auditing

*** Disclaimer, as I'm learning about Information Security I come across a lot of useful information. Truly, its a firehose of facts, tips, etc. that I write on this blog. As it were, I wish to post the following link along with my notes on the following topic - Security Audit. ***

blog.dashlane.com/conduct-internal-security-audit/

What is a Security Audit?

At its most basic, a Security Audit is a systematic technical assessment of a system or application. The Security Team will conduct interviews, perform all manner of vulnerability scans, analyze the results, and produce a report detailing areas that require attention.

An audit must be thorough, cost-effective (in both time and money),
and free of bias

A more expansive definition can be found by conducting an online search or visiting your local library or bookstore.

Who is this for?

Audits can be applied to banking, commercial, health care organizations, schools, and just about any other institution where there is an exchange or transmission of sensitive end-user data.

Why am I doing this?

As mentioned, anytime a transmission of sensitive user information is involved, there needs to be precautions taken to secure the data. Think: Banking or Retail Site using banking information to complete a transaction.

The CIA triad comes into play.

An audit guarantees data is kept confidential during processing, its integrity is preserved during transmission, and that it is accessible only to the recipients involved.

Security Audits are performed at the behest of a company about to launch an application employing sensitive user data. Another occasion an audit is conducted is mostly as a result of enforcement intervention (ie, a cyber crime was committed ). An investigation must be conducted to determine culpability by way of negligence, willful or otherwise.

Where will it take place?

More often than not, security audits are conducted on-site under the supervision of a third-party agency. Audits can be done internally or externally, the latter being more thorough but expensive.

External audits are performed by seasoned professionals who have all the appropriate tools and software to conduct a thorough audit   — assuming they receive the requisite data and direction

What is in scope?

Should you decide to conduct an internal audit, and you've educated yourself in the compliance requirements necessary to uphold security protocols. Do the following:

1. Define Your Audit
2. Define Your Threats
3. Assess Current Security Performance
4. Prioritize (Risk Scoring)
5. Formulate Security Solutions

What is not in scope?

Anything not otherwise agreed-to, as expressed in the contractual agreement, entered into by the auditor at the request of the client

What is to be audited and what is not will be documented in a list - Valued Assets - and divided into segments of what will / will not be audited. The assets declared highest value is where the focus of the audit should be.

How long does it take?

Start-to-finish, a security audit duration is determined by the scope and list of assets, as well as the volume of potential threats. Audits can span days or weeks. Most importantly, security audits are iterative and ought to be conducted regularly.

What are my deliverables?

Based on the outcome of the audit, a comprehensive report is generated detailing the level of tests conducted, any issues requiring action, and a list of potential security solutions. These can cover anything from "Employee Awareness" seminars, defensive counter-measures, better password policies, and network monitoring. 

This list can go on and on, but it is reliant mostly on the results of the aforementioned audit.

Product Review: Katalon v. 5.3

Katalon: The Automation IDE done right!!

Dearest Reader, Testers, and Engineers, I wish to take this opportunity to break away from my normal day-to-day to introduce you to a new tool I've been working with this past month. Normally, this blog is dedicated to all things relevant to Information Security, but I feel I must share knowledge as I have acquired it.
**DISCLAIMER: The following product endorsement is done so freely and willingly. I was not asked to publish this, nor have I received any endorsement by the company or any of its affiliates.

Ok, so what is Katalon?

By-and-large, Katalon is a testing framework built off Selenium. It is an IDE that features all the necessary tools a QA Engineer / Automation Tester would need to build out a comprehensive end-to-end test harness. The language of choice is Groovy, but any JAVA syntax will work. With a few choice imports, one can employ JS as well.

How does it work?

Once you've downloaded Katalon, you are presented with a dashboard of features. The interface is really intuitive, and within minutes, you can easily build out a test.

What can it do for me?

If you are new to automation and are not sure where to start, Katalon provides a recorder that is similar in concept to Selenium's IDE. Simply launch the recorder and right away you can build out your first test. Once you are done recording, you can export your test case and build it up as needed.
Not sure how to acquire page objects? No problem. Katalon features a "Web Spy" utility which allows you to map an entire page with just a few mouse-clicks.
For more seasoned professionals, the framework offers tremendous flexibility with regards to testing APIs, testing mobile applications (native and web app), and web applications. You can customize testing with "custom keywords" to build out scripts in a maintainable, reusable fashion.
Tests can be run across a variety of web browsers. As a stand-alone script, or as part of a test suite. Tests can be run locally, or as part of a continuous integration system. But don't take my word for it, look into it yourself. There's so much more to the IDE than I can possibly cover.

Where can I get it?

Go to Katalon.com