% DO NOT COMPILE THIS FILE DIRECTLY!
% This is included by the other .tex files.

\begin{frame}[t,plain]
\titlepage
\end{frame}

\begin{frame}
	\frametitle{Plan for this session}
	\begin{itemize}
		\item Quickly go over what is there in Cerebrate currently
                \item Implementation details
                \item The future
	\end{itemize}
\end{frame}

\begin{frame}
	\frametitle{Current scope}
	\begin{itemize}
                \item Basic UI and API systems (we'll talk about this later)
                \item First iteration of ContactDB
                \item Early version of the Trust Circles
                \item Basic User management and ACL
                \item Basic public lookup interface
	\end{itemize}
\end{frame}

\begin{frame}
	\frametitle{ContactDB}
	\begin{itemize}
		\item Repository of organisations and individuals
                \item Their relationships to one another (an individual can be affiliated with a set of organisations)
                \item Encryption keys associated with either
                \item Basic public lookup interface
	\end{itemize}
\end{frame}

\begin{frame}
	\frametitle{Trust Circles}
	\begin{itemize}
		\item Repository of sharing groups
                \item Sharing groups have metadata about their purpose and a list of member organisations
                \item Slightly simplified compared to MISP, this might change though
                \item Cerebrate sharing groups are not editable by anyone besides the source (up for discussion)
                \item They always have a primary owner
	\end{itemize}
\end{frame}


\begin{frame}
	\frametitle{User management}
	\begin{itemize}
		\item Users are tied to an individual - but not all individuals are users
                \item Authentication happens via username+password or an API key
                \item We can extend this in the future with other auth providers (for example LDAP) and optionally take this responsibility out of Cerebrate
                \item Users are tied to roles that can be custom defined
                \item Currently their affiliation to an organisation happens through the individual - though I will probably change this
                \item Users can have a set of API keys with different expirations / use-cases (based on MISP discussions this week we will enhance this further)
	\end{itemize}
\end{frame}

\begin{frame}
	\frametitle{Public lookup interface}
	\begin{itemize}
		\item Still more of a proof of concept
                \item The idea is that administrators can decide to open up a fully public interface for lookup services
                \item Currently the Individual and Organisation registries are optional parts of this system
                \item The plan is to be able to mark a list of orgs/individuals for the public lookups
                \item Separate url routing makes additional allow/deny lists on the URL easy to implement
	\end{itemize}
\end{frame}

\begin{frame}
	\frametitle{Internals}
	\begin{itemize}
		\item Largest part of the work was transitioning MISP APIs to a more modern stack
                \item UIs are generated by a diverse list of custom factories
                \item Everything is parametrised and standardised internally
                \item MISP's API libraries have been converted and modernised
                \item Same with the ACL libraries
	\end{itemize}
\end{frame}

\begin{frame}
	\frametitle{Deployment}
	\begin{itemize}
		\item Installation instructions are already available on github
                \item Very simple, low number of requirements
                \item Should run on a potato
	\end{itemize}
\end{frame}

\begin{frame}
	\frametitle{Main Next steps}
	\begin{itemize}
                \item Many things to do within the existing scopes
		\item Cerebrate to Cerebrate communication connections
                \item Automatic exchange of information
                \item Trust relationships
                \item Integration layer to instruct local tools
	\end{itemize}
\end{frame}



