Application Security and ASAP Framework

The principle of least privilege means granting only the minimum necessary access. Option C correctly states this: define exactly what each role CAN do, deny everything else by default. Group-based access (A) is an implementation detail, not the principle itself. Consistent checking (B) is about execution, not privilege assignment. Logging failures (D) is auditing, not the principle itself.

ASAP (Application Security Assurance Process) works best when integrated throughout the entire development lifecycle. Starting early in requirements analysis and continuing through rollout (C) allows security to be built in rather than bolted on. Applying it only during testing (A), development (B), or design (D) is less effective and more costly.

In the ASAP requirement analysis phase, the key activity is capturing security requirements and documenting them in the URS (User Requirements Specification) and SRS (Software Requirements Specification) documents (C). Simply capturing customer requirements (A) isn't enough - they must be specifically security-focused. Updating project plans (B) is a secondary activity.

The Development Team is responsible for fixing security vulnerabilities found during testing (B). They own the code and must implement fixes. The ASAP team identifies issues (A) but doesn't fix code. Testing Team finds vulnerabilities (C) but doesn't fix them. Project Management coordinates (D) but doesn't do remediation.

TCS ASAP offers three engagement models to suit different project timelines and requirements: Full-Fledged for comprehensive assessment, Staggered for phased approach, and Fast Track for accelerated timelines. The other options list pricing models (A) or delivery location models (B) which are not the engagement model types.

Static code analysis is performed during the design and build phase because it examines source code without executing it, identifying vulnerabilities early in development. Dynamic analysis (A) requires running the application and typically happens later during testing phases.

Penetration testing is the security-focused testing performed by ASAP teams during testing and rollout phase, simulating real-world attacks to identify exploitable vulnerabilities. Integration (A) and System (B) testing are functional testing types, while Unit (D) is done by developers.

TCS Security API is the TCS security library used for remediation of security vulnerabilities found during assessments. The other options (B, C, D) are plausible variations but not the correct product name.

During the analysis phase, ASAP provides Security URS (User Requirements Specification) and SRS (Software Requirements Specification) artifacts to guide the security assessment. Option D is incorrect because Security Design Guidelines (C) are not listed as provided artifacts for this phase.

The ASAP Team reviews security elements of updated project artifacts at the end of each application development lifecycle phase, ensuring security considerations are integrated throughout. The development team (A) creates artifacts, PM (B) manages overall project, and Testing Team (D) focuses on functional testing.

TCS ASAP is a security framework that provides methodology for application security assessment and integrating security into the SDLC. It's not just testing (C), nor a product (D) - it's a comprehensive framework. Option A calls it a methodology which is partially true but less accurate than framework.

The three essential steps for successful patch management are: 1) Acquiring the patch from vendor, 2) Testing it in non-production environment to ensure compatibility, and 3) Installing it in production. Option C misses the critical testing step. Option B incorrectly includes peer review and remediation.

The correct way to disable browser autocomplete is setting autocomplete='Off'. Options A (value '0') and D (value 'no-store') are not standard values for this attribute. Option C is too vague. The 'Off' value is the HTML standard for disabling autocomplete.