CRITs requires a somewhat involved level of administration. The reason for this is simply due to the sensitive nature of the data we are working with. It's very important to make sure we make no assumptions when it comes to the data and who gets access to it.

Note: If you are looking for System Administration stuff, scroll down to the bottom!

The security model for CRITs is currently based on what we call "Source Access". For any given user, they will only have access to read and write content for the sources they've been assigned access to. In some respects this is very restrictive and somewhat counter-intuitive. When you are looking to defend your network it would make the most sense to have access to all of the data available in order to perform your job. However, with so many organizations requiring agreements like NDA's being signed by every member of your organization, it becomes very difficult to manage.

We took this under consideration and decided that it makes the most sense to put assumptions side and require that all users be manually assigned access to the sources they should have access to. What does this mean for you as an admin?

Whenever someone adds a source to CRITs, no one, not even the person who added it, will get access to it. In order to get access to that source and admin must go into the Control Panel and manually add that source to every user that should have access to it.

Outside of source access, you have the ability to configure many settings that affect how user's authenticate and interact with the system. CRITs supports a couple authentication mechanisms:

• Basic: Usernames and passwords (encrypted) are stored in the database.
• LDAP: Authenticate against an LDAP server.
  • If you have an account in CRITs whose username matches that of your LDAP account and the LDAP server goes down, CRITs will automatically attempt to authenticate you using Basic Auth without you having to reconfigure the system.
  • You can read more about setting this up in the LDAP Setup Guide.
• Remote User Auth: If you have SSO or a portal that a user authenticates to, you can pass along that user to CRITs and it will authenticate them.
  • You can configure the system to create user accounts on the fly as users authenticate with Remote User, or you can set it so that you have to already have an account setup in CRITs before Remote User authentication will allow you in.

All authentication modes can be supplemented with TOTP. TOTP comes in two modes:

1. TOTP is globally disabled, but users can opt into using it if they wish.
2. TOTP is globally enabled and forced upon every user in the system.
   • This is broken down into two settings:
     1. TOTP Web: requires TOTP auth through the web interface.
     2. TOTP CLI: requires TOTP auth when using runscript.

Users can leverage any RFC-compliant TOTP authentication app to generate their Auth Token. Most commonly people leverage the Authenticator app by Google on their mobile device. If you have QRCode (https://pypi.python.org/pypi/qrcode) installed, CRITs will generate an image in the web interface that a user can leverage in the Authenticator app instead of having to type in the long string to seed their device.

You do not have to manage user passwords or reset passwords for users. There is a mechanism for resetting a user's password that utilizes the email address in their profile. If you don't want to have to manually reset passwords, make sure that you configure the Email host and Email port in the Control Panel. During the password reset window the user will be sent a reset code. That code is only good for 5 minutes. If the user attempts to brute force the reset code, it will be logged and become invalid after only a few attempts. After it has become invalid or the 5 minute timeframe has expired, the reset code will no longer work and the user will be required to generate another reset code.

User authentication also comes with some invalid login attempt tracking. When a user supplies an invalid password, the system will require they wait 10 seconds before trying again. Any attempt within that window will:

1. Be ignored.
2. Bump the wait time back up to 10 seconds.

Using the web interface the Login button is disabled for the 10 second duration. The reason for all of this is to prevent brute force lockout attacks on user accounts and limit the attack surface for TOTP brute forcing attempts. That being said, you can successfully authenticate as many times as you wish, as quickly as you wish, as long as your first authentication attempt is successful. This allows authenticated scripts to be run repeatedly without having to wait 10 seconds to run the next one.

In the Control Panel you have the ability to set how many invalid login attempts a user can have before their account is disabled.

Any user can add new menu items with the exception of a few:

• New Sources
• Updated TLD information
• User Roles

We don't allow users to create sources because sources require Administrator intervention to add those sources to users anyways. TLD update is a way for you to ingest the Effective TLD list (https://publicsuffix.org/list/effective_tld_names.dat) into CRITs. This is used by the system when parsing Domains so it is beneficial to keep your system up-to-date with it. Finally, User Roles are currently not very useful. Roles are being worked on and expanded currently so there's generally no need to use this feature unless your organization wishes to customize the code base to leverage it (this is really the only reason it's available currently).

There is not much else an admin can do that a normal user cannot. The one big thing is deleting top-level objects. Historically that's been left to admins so they can shoulder the burden of validating that the data is no longer necessary and can safely be removed. This also protects users from accidental deletion. This is also the same reason why there is no mass-removal of content in the interface. We believe in growing your data set often, and removing rarely. Even if the data doesn't seem useful now, re-scanning and re-analyzing old data as new technologies and methodologies arise can yield a diamond in the rough.

As the sysadmin for the server(s) that CRITs runs on, you've now also become the SME for MongoDB (congrats!). We highly recommend you become familiar with some of the following:

• How MongoDB works, how the data is stored on disk, what formats it can be retrieved in, map/reduce, aggregation, and the mongo shell (the last one can be a lifesaver!).
• How to backup your database!
• GridFS.
• How clustering works and how to migrate clusters. Once you get addicted to data, your system will grow quickly and you will need to keep an eye on it to determine when and how to expand.
• Your user's every day habits in CRITs and how you can improve performance using Indexes. We provide a decent set of Indexes (see the create_indexes management command) but you can always cater them to your needs.
• MongoDB upgrades. They release new versions fairly regularly and in many cases they come with awesome features and critical bug fixes. Since we use MongoEngine, and by extension, PyMongo, it is important to keep all three version-compliant. Sometimes that winds up not being compatible with CRITs code and we need to fix things. If you find yourself updating and things breaking, let us know so we can take a look at how to update the CRITs code to support newer versions. Better yet, send us a PR with how to fix it so we can give you credit for your yard work! ;)

On that last note, it is also fairly important to stay up-to-date with other dependencies. We do our best to test, validate, and support the latest versions of the critical software we use (Django, MongoDB, PyMongo, MongoEngine). If you notice a new version of a dependency we require and it:

1. Makes everyone's lives easier.
2. Makes CRITs more awesoming.
3. Fixes a huge security issue.

Please let us know so we can try it out! This also includes Operating Systems! We only support Ubuntu and RHEL. This is mainly because those are the systems our users have tried and tested. If you have an operating system that isn't currently supported and want to contribute, helping us support that OS would be a huge win! Whether it's another Linux distro, FreeBSD, OSX, or even Windows, we'd love to work with you to get dependencies and documentation up and available through the project for everyone else to benefit from.