tex: add basic structure, ideas, links
This commit is contained in:
parent
0592c99104
commit
4c3342cc33
160
tex/text.tex
160
tex/text.tex
@ -8,9 +8,169 @@
|
||||
% =========================================================================== %
|
||||
\part{Theoretical part}
|
||||
|
||||
\n{1}{Purpose}
|
||||
What this write-up is attempting to achieve.
|
||||
|
||||
|
||||
\n{1}{Terms}
|
||||
Introduce relevant terms.
|
||||
|
||||
|
||||
\n{1}{Cryptography primer} \label{sec:cryptographyprimer}
|
||||
Pre-requisities necessary for following up.
|
||||
|
||||
\n{2}{Hash functions}
|
||||
Explanation.
|
||||
\n{3}{Uses and \textit{mis}uses}
|
||||
The good the bad and the ugly of hash usage (including or in some cases
|
||||
excluding salting, weak hashes, split hashes (Microsoft)).
|
||||
\n{3}{Threats to hashes}
|
||||
Rainbow tables, broken hash functions...
|
||||
|
||||
\n{2}{Encryption}
|
||||
Generally.
|
||||
\n{3}{The key exchange problem}
|
||||
\n{3}{The key protection problem}
|
||||
|
||||
|
||||
\n{1}{Brief passwords history} \label{sec:history}
|
||||
|
||||
\n{2}{Purpose over time}
|
||||
|
||||
\n{2}{What is considered a password}
|
||||
|
||||
\n{2}{Problems with passwords}
|
||||
\n{3}{Arbitrary length requirements (min/max)}
|
||||
\n{3}{Arbitrary complexity requirements}
|
||||
\n{3}{Restricting special characters}
|
||||
|
||||
|
||||
\n{1}{Password strength validation}
|
||||
Entropy, dictionaries, multiple factors.
|
||||
|
||||
|
||||
\n{1}{Web security} \label{sec:websecurity}
|
||||
The internet being the vast space of intertwined concepts and ideas, is a
|
||||
superset of the Web, which is the part of the internet zoomed in on in this
|
||||
section.
|
||||
|
||||
\n{2}{Browsers} \label{sec:browsers}
|
||||
What they are, what do they do, how do they relate into the security aspect
|
||||
(privileged process running untrusted code on user's computer), history,
|
||||
present, security focus of the dev teams, user facing signalling (padlock
|
||||
colours, scary warnings).
|
||||
|
||||
\n{2}{Cross-site scripting} \label{sec:xss}
|
||||
|
||||
\n{2}{Content Security Policy} \label{sec:csp}
|
||||
|
||||
\n{1}{Sandboxing} \label{sec:sandboxing}
|
||||
\n{2}{User isolation}
|
||||
Admin vs regular user, privilege escalation, least-privilege principle,
|
||||
zero-trust principle.
|
||||
\n{2}{Process isolation}
|
||||
Sandbox escape.
|
||||
\n{2}{Namespaced isolation}
|
||||
Sandbox escape.
|
||||
|
||||
|
||||
\n{1}{Data storage}
|
||||
Among the key aspects of any security-minded system (application), the
|
||||
following are certain to make the count:
|
||||
\begin{enumerate}
|
||||
\item data integrity
|
||||
\item data authenticity
|
||||
\item data confidentiality
|
||||
\end{enumerate}
|
||||
|
||||
\n{2}{Integrity}
|
||||
|
||||
\n{2}{Authenticity}
|
||||
|
||||
\n{2}{Confidentiality}
|
||||
|
||||
\n{2}{Encryption-at-rest}
|
||||
|
||||
|
||||
\n{1}{Compromise checking and prevention}
|
||||
|
||||
\n{2}{HIBP and similar tools}
|
||||
|
||||
\n{2}{OWASP Top 10 for the implementers}
|
||||
|
||||
\n{2}{Password best practices}
|
||||
|
||||
|
||||
% =========================================================================== %
|
||||
\part{Practical part}
|
||||
|
||||
|
||||
\n{1}{Toolchain}
|
||||
|
||||
\n{2}{Development}
|
||||
\n{3}{A word about Nix}
|
||||
\url{https://builtwithnix.org/}
|
||||
|
||||
\n{2}{Production}
|
||||
|
||||
|
||||
\n{1}{Application architecture}
|
||||
|
||||
\n{2}{Data integrity}
|
||||
|
||||
\n{2}{Data authenticity}
|
||||
|
||||
\n{2}{Data confidentiality}
|
||||
At rest, only decrypted in memory when correct app key provided.
|
||||
|
||||
\n{2}{Connection security}
|
||||
|
||||
\n{2}{User isolation}
|
||||
In-application administrator does not posess the capability to see sensitive
|
||||
user data. The administrator only sees the number of tracked items and
|
||||
(potentially) number of active alerts (for breached credentials) for a given
|
||||
user.\\
|
||||
Least-privilege principle.\\
|
||||
Zero trust principle.
|
||||
|
||||
|
||||
\n{1}{Implementation}
|
||||
|
||||
\n{2}{Compromise checking}
|
||||
Periodicity, alerting mechanisms (email, Telegram..)
|
||||
\n{3}{Have I Been Pwned? Integration}
|
||||
\n{3}{Local Dataset Plugin}
|
||||
|
||||
\n{2}{Best practices}
|
||||
Describe built-in failovers and fallback mechanisms (request retries),
|
||||
collecting exposed app metrics and alerting based on their status.
|
||||
|
||||
Observability - in-app tracing collected by e.g. Jaeger
|
||||
(\url{https://jaegertracing.io}) or \url{https://opentelemetry.io/} - for
|
||||
superior performance insights on CPU, storage, network latency and jitter.
|
||||
|
||||
\n{2}{Database configuration}
|
||||
Decribe tuning for performance while also properly securing the DB.
|
||||
|
||||
The plan is to have 2 DBs: one for raw data (\url{https://postgresql.org}) and
|
||||
another one for checksum validation (\url{https://immudb.io/})
|
||||
|
||||
\n{2}{Deployment recommendations}
|
||||
Decribe in detail the following:
|
||||
\begin{itemize}
|
||||
\item behind a reverse proxy (TLS termination) or inside of a private network
|
||||
\item reasonable host security
|
||||
\end{itemize}
|
||||
|
||||
|
||||
\n{1}{Validation}
|
||||
|
||||
\n{2}{Unit tests}
|
||||
|
||||
\n{2}{Integration tests}
|
||||
|
||||
\n{2}{Click-ops}
|
||||
|
||||
% =========================================================================== %
|
||||
\nn{Conclusion}
|
||||
|
||||
|
Reference in New Issue
Block a user