What Is Risk Engineering?

  1. Risk Engineering Defined

  2. Threat Modeling And Advising

  3. Detection And Defense

  4. Trust & Safety Symbiosis

  5. Does My Company Need A Risk Engineering Team?






Risk Engineering Defined

Risk Engineering is a discipline dedicated to the detection, investigation, and remediation of abuse within the context of an online ecosystem. Its remit is bad behavior, a vast menagerie of offenses including credit card fraud, money laundering, account takeover, phishing, spam, harassment, blackmail, identity theft, and vaporware scams. Innumerable other site-specific transgressions, such as policy violations, also roost in Risk’s wheelhouse. While this taxonomy frames a generic map of the Risk Eng landscape, the joy of the work itself lies in particularity, in the challenge of combatting threats as diverse, beguiling, and dynamic as the human genius for getting one over.

Security is Risk Engineering’s raison d'être. Risk, however, is less a sibling than a young cousin to the traditional branches of security engineering, Application Security and Network Security. In practice Risk functions as a hybrid product and infrastructure team. Like a product team, Risk develops internal and user-facing features, owns integrations with third-party services, and is accountable for performance metrics such as “quarterly fraud losses.” Like an infrastructure team, Risk builds and maintains backend systems that power its capacity to identify and mitigate misconduct. Given this composite of properties, Risk can be difficult to classify and orient within an organization. Describing it in the familiar terms of its elders, AppSec and NetSec, helps elucidate Risk’s unique mission.




Threat Modeling And Advising

Like AppSec, Risk principally contends with external adversaries as opposed to malicious insiders. Further, both AppSec and Risk commonly support a product org through threat modeling, an exercise that entails inventorying a proposed feature’s attack vectors and advising on how to eliminate or harden soft spots. Whereas AppSec tends to spotlight flaws in code, Risk illuminates how functionality itself can be exploited, even when it has been programmed properly and works as intended. For example, consider an online marketplace that is spec’ing out a messaging service that enables communication between buyers and sellers. AppSec might recommend an architecture that ensures the confidentiality of conversations, and, once development is underway, flag endpoints that are vulnerable to SQL injection. Risk, alternatively, would counsel the implementation of safeguards such as rate limits to prevent spam, levers to mute harassment, and pattern-matching filters configured to surface illicit content.




Detection And Defense

Dispensing guidance is a critical but narrow duty of Risk Engineering. More dominant Risk prerogatives include detection and defense, mandates that map to core network security tenets. Detection – discovering objectionable activity – requires isolating faint signal within thunderous noise. Identifying anomalies is predicated upon baselining, the artsy science of defining expectations for particular behaviors within specific contexts. For example, establishing how many bytes of data devices usually upload to remote hosts within a timeframe. Any machine that radically exceeds this threshold would trigger an alert, ideally enriched by details such as the destination URL of the transfer, whether or not it took place during working hours, and the nature of the sender itself. The smart toaster in the company kitchen, for instance, should be exfiltrating bagels, not trade secrets.

Risk Engineering has adopted baselining techniques codified by NetSec and applied them to end-user activity. For example, Risk might set a standard for how many credit cards customers tend to add to their accounts within a span of time, and further, what percentage of those cards tend to fail authorization. Flagging and investigating sharp deviations from norms is a natural next step.




Trust And Safety Symbiosis

Trust & Safety and Risk Engineering are existentially interdependent. Each is not just diminished, but rather, hamstrung without its complement. They inhabit a shared problem space with discrete perspectives. Risk brings a holistic view by virtue of the dashboards that it monitors, the diagnostics that it logs, and its insight into code and data proper. This panoramic vantage empowers Risk Eng to discover attacks by observing prominent aberrations. For example, a surge of failed login attempts attributed to an esoteric ISP. The success of Risk’s methodology hinges upon measuring the right events in the right ways, and so blind spots are inevitable. T&S fills these lacunae. By manually investigating user-submitted fraud reports and the alerts generated by automated Risk controls, T&S maintains the most current, precise, and empirical comprehension of trends. Risk engineers track vast meteorological forms; T&S agents live the weather. Working together, they achieve macro-visibility and micro-sensitivity, which is to say, comprehensive coverage.




Does My Company Need A Risk Engineering Team?

Effective Risk Engineering programs reduce fraud losses and enhance brand reputation. Cultivating a robust Risk team is imperative for e-commerce and FinTech businesses, and prudent for any platform that facilitates the transaction of messages, goods, or services. Companies often struggle, however, to divert budget away from growth, and may decide not to invest in an anti-fraud and abuse division. As a result, Risk Engineering’s mandate will be fragmented across the sundry teams closest to assorted menaces. For example, Payments Engineering might battle credit card testers while Site Reliability Engineering repels DDoS and an Internal Tools group flexes to quash ATO. Opting not to plan out and build a dedicated Risk Engineering team is thus tantamount to sanctioning the evolution of a distributed one. This arrangement may be optimal for small organizations, and tenable even for larger ones. Three factors of scale, however, strain its longterm viability.

First, a decentralized defense is conducive to gaps. Nuanced vulnerabilities will go unseen if specialists are not actively scanning for exposure. Others may be ignored, especially when they do not fall squarely within a given team’s purview. A coordinated defense, alternatively, minimizes these oversights with the added benefit of preventing duplicative work.

The second factor is incentive. During the ferment of a company’s adolescence, engineers are often lauded for versatility, and so motivated to don a Risk hat when exigent. As corporations mature, however, divisions of labor crystallize. Omnibus teams are restructured and tasked with mastering one function. Every deviation from this defining focus jeopardizes the unit’s success, and may even be penalized as a misallocation of resources. This model discourages Payments Engineering, for example, from prioritizing curbing credit card fraud over launching a guest checkout flow. In such circumstances, it is essential to support a Risk Engineering team whose performance metrics are directly tied to thwarting malfeasance.

The final condition blends the related elements of volume, expense, and sophistication. The amount of abuse that a platform brooks often reflects its prominence. As a company’s brand awareness and active user base rise, a chronic barrage of attacks may overwhelm teams accustomed to addressing sporadic threats on an ad hoc basis. Escalating fraud usually translates to an ascendant chargeback rate and deteriorating user experience. The advent of these alarming effects should cue discussions about creating a Risk Engineering team. A subtler impetus, one difficult to quantify or capture in user surveys, is the complexity of abuse that beleaguers a site. Bad actors in the Risk space are rarely characterized as advanced, especially when juxtaposed with technical threats groups that prioritize stealth and persistence over quick paydays. Though regularly underestimated, professional fraud rings often operate with bedeviling resourcefulness and exhausting resilience. Every impediment, from strict rate limits to mandatory 2FA, is merely a forcing function for criminal adaptation. A specialized Risk Engineering group is best suited to square off against such tenacious threat groups. Vigilance requires both bandwidth and interest that may be scarce among teams moonlighting in the Risk world. Further, expertise accrued through experience equips Risk Engineers to work strategically, predicting attacker mutations and designing countermeasures in order to circumscribe damage.