Posts Tagged ‘ SQS ’

QA Program Manager – Chicago – Long term contract SQS

 

sqs logo

 

QA Program Manager – Long term contract – Chicago – Banking industry

 

 

-Strategic program called “Cash”

-Oversee wholistic vision for the program.  Overall test strategy.

-Agile

ALM & Jira

-Organized

-Assertive

-Consensus Builder

-Status Dashboards

-PM Experience valued

Description:

Strategic Test Manager to oversee the first phase of a multi-phase program.  The selected candidate will be responsible for the overall quality of testing, related deliverables and resources.

 

  • Trading Life Cycle and/or financial domain experience required. European financial market testing knowledge and experience preferred.
  • 7-10 yrs or equivalent experience leading test efforts for strategic program.
  • Great Presentation/Communication skills – ability to communicate with all levels of management and tailoring communication to the audience
  • Experience creating program estimates for testing across SIT, UAT, Automation and Performance test phases.
  • Some experience with Automation concepts, enabling applicable benefit recognition and promotion of opportunities for such.
  • Knowledge of Test Management with ALM is required.

 

Skills:

Qualified candidates experienced in any or all of the following are preferred:

  • Database/Oracle validation
  • UI interface validation
  • XML Validation
  • Swift Message types and validation

 

Good understanding of IT delivery methodologies & Test Strategy creation

Ability to understand Business processes and translate into requirements, monitor testing and assessing impact of slippage

Test case review, Test Scripting & managing test prerequisites

Test execution support, defect triage, execution metrics generation/reporting, and completion sign off

Strong Ability to develop/groom a team of Consultants/Senior Consultants for an engagement

Ability to manage test resources in an onsite-offshore team environment – sharing ideas and working collaboratively.

 

Additional Skills:

Strong communication skills, both written and verbal in order to contribute to design discussions, interpret use cases and create comprehensive test plans and scripts which can be understood and approved by business stakeholders.
Should be able to drive customer discussions independently and act as trusted advisor
Positive & adaptable and able to work under pressure in a continually changing environment
Strong team player who is able to build strong relationships across the program – from developers through to business stakeholders.
Solid general understanding of business processes, core systems, policies and procedures that contribute to user testing of systems and processes.
Excellent time management skills with the tenacity to achieve tight deadlines

QA Analyst – NYC – Wall Street – Long term Conract

sqs logo

 

The QA Analyst is a member of the Quality Assurance-US Team and will be required to work on QA projects for NYSE Arca Exchange platforms.

 

Knowledge, Skills, and Experience Required

 Bachelor’s degree (B.S.) from a four year college or university with a major in computer science, finance or mathematics

 Must Have test complete and protractor 3+ experience

 Must have 5+ years’ work experience in a QA role.

 Must have 3+ Unix (Linux/Solaris) experience required. Scripting in perl or shell is required.

 Must be proficient with SQL

 Knowledge of SQA methodologies and practices

 Strong analytical and problem solving skills

 Must be a fast learner, flexible and able to work independently on tasks assigned.

 Very good verbal and written communication skills

 Ability to work in a highly demanding, fast paced environment

 Knowledge of FIX protocol is a must.

 Experience with trading and financial applications is a plus

 Must Have test complete, Selenium and protractor 3+ experience Key Accountabilities

The role requires frequent interaction with Developers, Business Analysts, Client Support Analysts and other members of the QA team to ensure that collectively we deliver a quality-trading platform to our customers.

The essential functions of the position include, but are not limited to:

1. Work closely with various members of the IT team and Business to understand business and functional requirements of the project and leverage them to design and develop a comprehensive test plan and test cases to cover project scope.

2. Perform automated functional and regression testing on exchange software releases. Document results, identify discrepancies, troubleshoot and report defects and track them to resolution.

3. Manage software issues and test activities ensuring QA policies and standards are met, throughout the QA testing cycle.

4. Work closely with other QA members to create/maintain regression scripts.

5. Work independently on tasks assigned.

 

Security Test Automation – Westport CT – Contract

sqs logo

 

Long term contract in large security testing environment. Location is in Westport, CT.  SQS.COM

 

 

Job Description:

This resource is expected to work on the following areas :

  • security testing (OWASP tooling integration)
  • configuration & deployment testing and
  • performance testing

Pen test – threat modeling/review – Contract – San Francisco

sqs logo

 

Description of Services: SQS will perform threat modeling and security architecture reviews. The tasks will be based upon clients methodologies and requirements in order to conduct said reviews.

 

Threat Modelling

Threat modelling is a structured approach for analyzing the security of an application and enables the identification and quantification of security risks associated with applications or solutions. Threat modelling is typically performed early within the SDLC with its purpose being to identify threats and potential vulnerabilities within an application through the review of application design and specification documentation to identify controls for inclusion as security requirements in the development of the application.

Our approach to Threat Modelling is modularized and iterative which enables it to be used within Waterfall and Agile development approaches. This is to allow for elements of the Threat Modelling process to be performed as the supporting information for the application becomes available.

Our standard Threat Modelling Process contains the following steps:

• Understand and Modelling the Application

? Determine the Security Objectives of the Information/Application

? Identify the Information Data Flows

? Identify the User Roles

? Identify the Trust Boundaries

? Identify Entry and Exit Points

? Identify Authentication and Authorization Decision Points

? Identify Threats

• Develop Security User Stories or Abuse Cases

? Use STRIDE or DREAD as appropriate to rank threats

? Identify Potential Controls

? Develop risk mitigation strategy

 

Each of the above steps are documented as they are carried out and the resulting document is the threat model for the application which can be used to support design decisions

Security Architecture and Design Review

A Security Architecture and Design Review (SADR) is a structured method for reviewing the security of a system architecture at multiple levels and provide practical remediation actions to ensure maximum system security. This is performed throughout the design and implementation of a system comprised of multiple computer systems interconnected via a network.

SQS performs SADR’s to ensure that the underlying infrastructure of specific systems are secure. This includes three levels of analysis each intended to address security from the logical almost ethereal level all the way down to the hardware level.

Security Requirements Assessment

A Security Requirements Assessment is performed to ensure the system adheres to the security requirements put forth in the early stages of system development. It is intended to ensure there are no glaring security gaps in the design of the system. To perform a Security Requirements Assessment, SQS will require information such as architecture diagrams and documentation describing the intended workflow of a system, as well as the roles of its users. The following are the three key phases that will be conducted during the Security Requirements Assessment.

Security Requirements and Design Documentation

SQS will require any and all documentation pertaining to the requirements and design of the Page 3 of7

 

system. This includes, but is not limited to:

• Use case documentation

• Technical specifications

• Developer notes

• Administration and user manuals

• Deployment and maintenance manuals

• Network diagrams

• Existing Data Flow Diagrams

• System design diagrams

• Interconnections within the system

• Connections with external systems and networks

• Data storage mechanisms

 

Interview stakeholders and developers

In order to cover the gap in the available information and put the existing documentation in context, SQS will interview all of the project stake holders as well as available project managers and a small sampling of developers. All questions are derived from the existing information and should be answered honestly to the best of the interviewed ability. Contradictions and inconsistencies will only lengthen the process and might require re-interviewing. The estimated timeframe for this phase is dependent upon the number of personnel required to be interviewed. Ideally this step only requires a couple of days to achieve.

Analysis

SQS security architects will collate, normalize and analyze the compiled information.

Infrastructure Configuration Review

An Infrastructure Configuration Review is performed in order to maximize the security of the physical system. This process utilizes the results of the Security Requirements Assessment to guide SQS security architects in the review of physical configurations of the target system(s).

System documentation and network diagrams

SQS security architects will require any and all documentation pertaining to the hardware and software used to make up the physical system. This includes, but is not limited to:

? Administration and user manuals

? Network diagrams

? Interconnections within the system

? Connections with external systems and networks

 

Interview stakeholders and administrators

In order to cover the gap in the available information and put the existing documentation in context, SQS will interview all of the network stake holders as well as available system administrators. All questions are derived from the existing information and should be answered honestly to the best of the interviewed ability. Contradictions and inconsistencies will only lengthen the process and might require re-interviewing.

Individual system configurations

In order to provide a detailed and in depth review of not only the entire system but of the individual components of the system, detailed configuration descriptions or actual configuration files are required for every piece of hardware and software used in the system. Each of these configurations will be reviewed in detail against the existing security requirements, industry Page 4 of 7

 

standards and best practices.

Analysis

SQS security architects will analyze the documentation and configuration files provided. Each of the configurations will be reviewed in detail against the existing security requirements, industry standards and best practices. SQS uses various configuration guides, checklists and standards published by NIST, SANS and other reputable security organizations to perform the review.

Infrastructure Penetration Test

This is the last step in the SADR and is intended to leverage the customer network in certain real life scenarios based on the information gathered in the previous steps. This provides additional evidence for a customer that the system(s) can withstand an attack from both internal and external adversaries.

Preparation

At this point in the SADR a wealth of information has been gathered on the target system(s). As Infrastructure Penetration Tests are frequently performed on live deployments, a scope will be defined. The scope identifies the systems that are to be tested as well as limits on types of tests to be performed. If applicable, SQS will review architecture diagram, placement of servers, network segregation, and VLAN usage, etc.

The exact scope of a penetration test is agreed during the planning and initiation phase but in general the aims of each penetration test will be to assess the security of internal and external infrastructure and to provide assurance over the security configuration of the in-scope systems. In some cases, the penetration phase will provide access to previously inaccessible hosts or networks, and in these cases, the test team will move on to test the newly-visible infrastructure, beginning again with the network mapping phase. In this sense, the sequence of test execution can become recursive. At all times, the test team will take care to avoid infrastructure that is out of scope, and will not exploit vulnerabilities that may have adverse effects on live services without prior consultation with the designated technical contact.

1. Public Information Discovery

2. Public-Facing Address Confirmation

3. Network Mapping Phase

4. Vulnerability Mapping Phase

5. Penetration Phase

 

SQS will then attempt to gain access to CLIENT’s network by leveraging the vulnerabilities and weaknesses discovered to a point where we are in a position to compromise information or the integrity of your network. SQS may use vulnerability scanning tools to scan the target network and systems with all its varying configurations of hardware and software, but while these scanners can perform the bulk of the scanning, manual verification is necessary to eliminate false positives, expand the scope, and to discover the data flow in and out of the network. Manual testing refers to a person or persons at the computer using creativity, experience, and ingenuity to test the target network in view of penetrating the network using SQS’ own techniques.

Manual verification is carried out using combinations of the tools listed previously, in addition to proprietary tools and simple clients such as those for Terminal Services, HTTP servers, MS-SQL, CIFS file shares, NFS exports, NIS, LDAP servers. Network configuration issues are not normally exploited as this can lead to network failure. However, should exploitation be desired, this is accomplished using tools such as Zebra and hping.

 

Exploitation of common host-based vulnerabilities is facilitated by the use of frameworks such as metasploit and canvas, whilst on-host data gathering is achieved by tools such as cachedump, lsadump and pwdump in conjunction with proprietary tools that are essentially batch files or shell scripts wrapping system tools such as the Windows net command and standard UNIX shell utilities. These techniques are considered aggressive, and will not be used on hosts providing live services without the permission of the technical contact.

Deliverables

SQS will provide the following deliverables to CLIENT:

? Weekly status updates

? Preliminary report

? Final report