Проверка СБ при приёме на работу: что смотрят и как пройти

Main ideas, concepts, and lessons

1) Information security is commonly divided into major areas

• Infrastructure security (often works closely with DevOps/IT ops)

  • Focus: securely operating infrastructure services.
  • Includes: securing/configuring network devices and services (e.g., Active Directory).

• Code / Application Security

  • Focus: securing software and applications.
  • Includes: web protections, pentesting, and web application firewalls (WAF).
  • Uses: static/dynamic analyzers and dependency/vulnerability search, including checks of libraries/dependencies.

• Methodology / Governance

  • Focus: creating and maintaining policies, monitoring their implementation, and ensuring compliance (including personal data protection as required by law).

• Security Operations Center (SOC)

  • Focus: collecting and processing security-relevant events (monitoring from a security perspective).
  • Usually tied to: infrastructure security monitoring.

2) Security architects are “cross-cutting” and focus on system-level risk

Architect responsibilities vary by company, but typically include:

• Viewing the overall security system and deciding “what to do next.”
• Having advanced technical skills plus soft skills, especially systems thinking.

Common architect duties described:

• Architectural review of software/product changes:

  • Gather information from developers about:
    • data flows
    • processed data
    • file storage locations
    • overall system structure
  • Assess risks of leaks or weaknesses.
  • Propose/require protective measures (and how to apply them).
  • If something is outside the architect’s expertise, consult specialists from other domains (e.g., infrastructure or application security).

• In some companies, the architect holds process ownership for “security review” during development (a gate before release).

3) Specialists vs architects: not everyone needs the same depth in every area

• Application security people:
  • often know programming well and use specialized tools to detect vulnerabilities/dependencies.
• Infrastructure/security governance people:
  • focus more on higher-level architecture and process/maturity.

Key distinction implied: Architects coordinate across domains, ensuring requirements and risk coverage are addressed end-to-end.

4) Security processes can slow development, but the goal is risk management—not blanket blocking

• The speaker addresses the criticism that security teams “block everything.”
• Lesson/response:
  • Security restrictions exist because risks must not materialize.
  • Effective security management means:
    • improving process speed (e.g., faster approvals/access)
    • allocating enough resources
    • using good governance rather than only prohibitions

Tradeoff highlighted:

• Too strict bans can lead to workarounds (temporary tunnels, layered exceptions, unofficial routes).
• Workarounds can create new security holes, sometimes worse than handling things “normally.”
• Workarounds can be abused by internal attackers, not only external ones.

5) “You can’t fully remove hacking risk”—security has to balance usability and protection

• Core message:
  • It’s impossible to prohibit everything (e.g., “unplug the computer”).
  • Security aims for a balance, but perfect balance is rarely achievable.
• Mentioned framing:
  • Not “if you get hacked, but when you get hacked,” reinforcing preparedness and controls.

6) AI/LLMs lower the barrier for exploitation, but security mechanisms still largely revolve around known issues

Speaker’s view after LLM popularization:

• Threat potential increases in speed/scale of exploitation support (e.g., generating proof-of-concepts).
• However, no fundamentally new classes of vulnerabilities are claimed.

Example described:

• LMs help assemble proof-of-concepts faster for a specific target environment—attackers benefit too.

Also noted:

• More hacking-bounty participation and reports can overwhelm security triage capacity.

7) Role-based risk: “support” and privileged access can be highly risky if mis-scoped

The speaker argues operational roles (example: IT support) may have extensive access:

• repairing machines for top managers
• installing software/agents
• potentially wiping disks or moving/copying data
• sometimes with poorly logged/tracked actions

Lesson:

• Proper separation of duties, least privilege, and strong controls (e.g., disk encryption and controlled access paths) matter.
• Security risk is not only logical access—physical and operational pathways matter too.

8) Hiring/security vetting: security provides risk information; the hiring manager decides

Described characteristics:

• Security acts like screening/recruiter-like HR support, including:
  • conflict-of-interest risk
  • legal/administrative/criminal concerns (scope depends on company)
  • overall risk assessment by category

Conceptual process (“traffic light”):

• Security provides an assessment to the hiring manager:
  • red = not recommended
  • yellow = questionable/needs thinking
  • green = acceptable
• The hiring manager makes the final decision (banks may apply stricter pressure).

Notes:

• Administrative/criminal/legal checks depend on business context.
• Relevance of old incidents varies by company.
• Cross-validation of resumes/profiles may not always be complete unless required.

9) Polygraph tests are viewed skeptically as a weak tool

Speaker’s stance:

• Polygraphs are a “waste of money” because many people pass.
• The speaker believes the data has little scientific value.
• The only possibly useful part is the examiner interview process (question framing, psychological pressure), but evidence of effectiveness remains weak.

10) Hiring and career advice: select based on fundamentals + soft skills, not only bootcamp claims

Emphasized criteria:

• Basic understanding is required (at least broad literacy):
  • programming concepts
  • networks
  • operating systems
  • plus security-specific direction
• Soft skills are highly valued, especially for abstract roles (communication, contract/process resolution).

Realism about career paths:

• Moving toward DevOps from help desk is discouraged unless the person gains an infra/system-admin perspective (e.g., Linux, networking, databases, multiple environments/teams).

Skepticism about short courses:

• Programs framed as “3 months then you can work” are viewed as unrealistic because security needs hands-on practical experience.

11) Internships: mixed view; real internships exist, but scams may exist

Speaker’s experience/knowledge:

• Some scam-like schemes may require students to pay and “lose” their first salary.
• Large companies can run structured internship-to-employment pathways:
  • limited-term contract initially
  • extension/permanent placement if performance is strong

12) Interview style depends on role seniority and the company

• Technical interviews:
  • may include system-design and role-relevant security questions for more technical roles.
• Less technical roles:
  • interviews may focus more on experience than deep technical questioning.

Implication: relevance and role fit matter more than one-size-fits-all interview formats.

---

Methodology / process instructions explicitly described (detailed bullets)

A) Architectural review / security review process (as described)

Trigger:

• Developers create a feature/product.
• A security review is required at some point before/around release.

Architect collects required system knowledge from developers:

• identify and document data flows
• specify what data is processed
• determine where files are stored
• understand system structure/architecture

Architect performs risk assessment:

• look for possible leaks or exposure points
• evaluate whether protective measures are needed

Architect coordination:

• if the architect lacks depth in a topic:
  • escalate to infrastructure security specialists
  • and/or to application security specialists

Outcome:

• protective measures are defined and requirements are enforced through the organization’s security process.

B) Application security checks (tool-based approach)

Use security testing/analysis tools:

• static analysis
• dynamic analysis
• dependency search / dependency & vulnerability checking

Check what the developer’s solution relies on:

• vulnerabilities in dependencies
• dangerous dependencies
• whether only approved libraries are used (or similar constraints)

Use pentesting/web defenses when applicable:

• web protection mechanisms and WAF
• pentesting for realistic exploit validation

C) Hiring vetting workflow (conceptual “traffic light” model)

Security department performs risk screening:

• resume/profile review
• conflict-of-interest considerations
• legal-related checks (administrative/criminal relevance depending on company and role)

Security produces a risk recommendation:

• red = not recommended
• yellow = risk/uncertainty; “plus or minus”
• green = acceptable

Hiring manager makes the final decision:

• if they accept the assessed risk, they hire; security has warned and provided the assessment.

---

Speakers / sources featured

• Alexey — main speaker; experienced information security professional, described as an information security architect

Mentioned organizations/companies (context only, not as speaking sources):

• Monolith Bank
• Positive Technologies
• products/tools mentioned: Maxpatel, Spider
• Otkritie Bank
• Rambler Group
• Mail Group
• Mail.ru group
• SБ Bank / “SB Bank” (as referenced by speaker)
• Betting/Bookmaker (generic mention)
• Yandex
• Amazon/Azon (as examples for internships)
• biofonic.com (appears as a channel/site marker; not a person speaking)