When Being Hot Is Not Cool: Monitoring Hot Lists for Information Security
Bibliographic record
Abstract
We study operational and managerial problems arising in the context of security monitoring where sessions, rather than raw individual events, are monitored to prevent attacks. The objective of the monitoring problem is to maximize the benefit of monitoring minus the monitoring cost. The key trade-off in our model is that as more sessions are monitored, the attack costs should decrease. However, the monitoring cost would likely increase with the number of sessions being monitored. A key step in solving the problem is to derive the probability density of a system with n sessions being monitored with a session’s age measured as the time elapsed since it last generated a suspicious event. We next optimize the number of sessions monitored by trading off the attack cost saved with the cost of monitoring. A profiling step is added prior to monitoring and a resulting two-dimensional optimization problem is studied. Through numerical simulation, we find that a simple size-based policy is quite robust for a very reasonable range of values and, under typical situations, performs almost as well as the two more sophisticated policies do. Also, we find that adopting a simplified policy without using the option of managing sessions using age threshold can greatly increase the ease of finding an optimal solution, and reduce operational overhead with little performance loss compared with a policy using such an option. The insights gained from the mechanics of profiling and monitoring are leveraged to suggest a socially optimal contract for outsourcing these activities in a reward-based contract. We also study penalty-based contracts. Such contracts (specifically, when the penalty is levied as a percentage of the monthly service fee) do not achieve the social optimum. We show how an appropriate penalty coefficient can be chosen to implement a socially optimal penalty-based contract. In addition, we provide a high-level comparison between reward- and penalty-based contracts. In a penalty-based contract, the setting of the fixed payment can be challenging because it requires additional knowledge of the total expected malicious event rate, which needs to be observed through a period of no monitoring.
Fetched live from OpenAlex and de-inverted. Abstracts are not stored in this database: the inverted indexes are 8.6 GB of the frame’s 9.3 GB of text, and the host has 13 GB free.
How this classification was reachedexpand
Full frame machine prediction
Teacher imitationNot calibrated prevalence, not ground truth. Human validation pending. The Gemma side is a direct model label for every work in the frame, read from the title-only record. The Codex side is a classifier learned from the 10,348 direct Codex labels and calibrated to design-weighted sample rates; fields without enough sample support carry no Codex call. Candidate is the union of the two sides; consensus is their intersection. These outputs are machine_predicted_unvalidated and are not human labels.
Distilled classifier scores by category (both heads)
| Category | Codex | Gemma |
|---|---|---|
| Metaresearch | 0.006 | 0.020 |
| Meta-epidemiology (narrow) | 0.001 | 0.001 |
| Meta-epidemiology (broad) | 0.001 | 0.001 |
| Bibliometrics | 0.001 | 0.001 |
| Science and technology studies | 0.001 | 0.002 |
| Scholarly communication | 0.003 | 0.007 |
| Open science | 0.002 | 0.002 |
| Research integrity | 0.002 | 0.002 |
| Insufficient payload (model declined to judge) | 0.005 | 0.000 |
Machine scores (provisional)
The two teacher heads of the student model, read on this work. A score orders the frame for review; it never asserts a category, and the validation status ships verbatim with every row.
Baseline scores from an immature model (maturity gate not passed, 7 training rounds). Scores rank; they never assert a category.
score_only:v0-immature-baseline · verbatim from the scoring run: score_only means the number may rank works, and no category label ships from itClassification
machine, unvalidatedMachine predicted; a candidate call from one source (direct Gemma or distilled Codex), not a consensus.
How this classification was reached, model by model and score by score, is at the end of the page under "How this classification was reached".